Zend FR

Hello,

Zend_Db est une classe. C'est une Factory ("design pattern factory" sur le net).

Zend_Db_Adapter_Abstract est une classe abstraite car elle n'est pas concrètement liée à une base de données. Elle regroupe des méthodes communes à tout adaptateur concret en décrivant des méthodes abstraites qui devront être concrètement déclaré dans la classe d'adaptateur finale.
Quand ton code utilisera un adaptateur (n'importe lequel), il ne saura pas concrètement lequel il a en face de lui mais saura les méthodes qu'il pourra utilisé.
Par exemple, on sait qu'un adaptateur concret possèdera la méthode _connect(), celle-ci variera en fonction de la base de données.

La classe Zend_Db_Adapter_Pdo_Abstract regroupe des méthodes à tous les adaptateurs de type pdo sans pour autant être concrètement lié à une base de données donc elle reste abstraite.

Il ne faut pas confondre classe Abstraite et Interface (voir aussi sur le net).

A+

Dernière modification par mikaelkael (21-11-2008 13:16:49)

C'est très simple en fait.
si je te dis pour aller à lyon tu prends une voiture, tu passe à la station
tu fait le plein de la voiture et tu file sur l'autoroute
etc.

Tu comprends facilement que tu dois avoir une voiture pour faire cela et que la voiture de mon discours ne te perpétra pas d'aller à lyon.

bref pour mettre en place la procédure aller à lyon j'ai besoin d'une voiture. mas matérielle, juste la notion de voiture. une voiture abstraite.

si je te donne la procédure. il te suffit de trouver une vrai voiture une voiture concrète pour pouvoir aller à lyon.

dans ZF c'est la même chose. il a par fois besoin d'une notion au sens large pour définir son algorithme mais il lui faudra une vrai instance de la chose pour la mettre en œuvre.

c'est le cas par exemple l'accès à la base. pour pouvoir fonctionner il lui faut un objet qui représente l'accès à la base. peu importe comment il fonctionne peut importe quelle base. il suffit qu'il remplisse un certain nombre de critères (API)
pour définir ces critères de façon générale on vas utiliser une classe abstraite Zend_DB_Adapter_Abstract.

tout objets qui sera un Zend_DB_Adapter_Abstract sera utilisable pour accéder à une base de donnée. j'ai donc tout ce qu'il faut pour construire mes objet utilisant une base.

mais si je ne fait pas une vrai classe qui sais se connecter à une vrai base ça ne fonctionnera pas.
On va donc faire des classes dérivées qui elle seront concrètes. comme ce sont des classe dérivées. elle aurons obligation d'implémenter toutes les méthodes abstraites.

de cette façon les classe qui utilisent Zend_DB_Adapter_Abstract pourront utiliser ces classes concrètes.

ainsi un ensemble d'objet peut utiliser un adaptateur pour se connecter à une base sans avoir à savoir quel type de base. pour que le système fonctionne avec de nouvelle base il suffit d'ajouter des adaptateurs.

On pourrait très bien utiliser un classe concrète. (imagine qu'à chaque fois qu'on te fourni un manuel d'entretien automobile tu te retrouve avec tous les vrais outils toutes les vrais pièce et la vrai voiture, le marché des manuel serait une vrai galère)

bref on pourrait avoir un Zend_Db_Adpater concret donc dont tous nos adapter spécifique à un type de base dérive. ça marcherait de la même façon.
sauf que rien n'empêche de créer un objet de cette classe et de l'utiliser pour se connecter
Mais à quoi vu que cette classe ne connait aucun moteur ?
là à la rigueur ça demande un peut de vigilance.
Mais si elle est concrète elle vas avoir toute les méthode qui ne feront rien ou n'importe quoi.
que se passerait-il si une classe dérivée n'implémentait pas une de ces méthodes ?

ce serait vite la cata.
Les classes abstraite vont donc permettre de rendre du code très générique et de maitriser les classes concrètes qui en dérive.

pour les interface c'est un peut différent.
dans les système objet à base de classes il peut être intéressent de définir de l'héritage multiple.

par exemple j'ai une classe feuille de calcul qui me fourni une multitude de méthode de calcul sur des grille de données.
j'ai d'un autre côté une superbe classe document qui sait faire de belle impression
pour faire une facture il est très simple de voir qu'avec un double héritage je vais facilement construite ma classe facture.

une facture est bien une feuille de calcul bien présenté et imprimable.

mais voilà c'est plutôt difficile à mettre en œuvre l'héritage multiple. l'héritage simple suffit souvent.

alors comment faire ?

on constate que dans de très nombreux cas ou l'héritage multiple semble être la seule issue on a en fait un héritage concret et un héritage abstrait.

essayez d'imaginer la complexité de ma classe document ci-dessus si elle est concrète. il faut qu'elle sache mettre en forme quasiment tout type de document....

en fait c'est typiquement c'est une classe abstraite dont de nombreux type de document dérive et implémente les méthodes.

ma classe facture dérive donc d'une classe concrète feuille de calcul et d'une classe abstraite document. c'est très souvent le cas.

dans ce cas là ont peut s'en tirer avec un héritage simple. il suffit de prendre pour convention qu'on n'a pas de classe document mais que toutes les classes qui voudront se comporter comme telle devront implémenter un ensemble de méthodes.

ce contrat que l'on définit ainsi s'appelle une interface. ma classe facture va donc dériver de feuille de calcull et s'engage à implémenter le contrat d'interface des document.

Une classe manipulant les document sera donc en mesure de l'utiliser.

A+JYT

Bon, je n'ai pas pu répondre avant parce que je suis pas mal débordé en ce moment. J'ai tout lu et certains points se sont éclaircis
Je vais compléter vos explications et exemples avec les annexes du bouquin de Julien mais aussi de Guillaume sur le ZF :p

Merci à tous pour vos réponses, je ne m'attendais pas à tant de détails. Vraiment merci.

Dernière modification par miboo (11-12-2008 17:49:09)

gauthier a écrit:

les annexes du bouquin de Julien sur le ZF

de Julien ET Guillaume

Bah quoi c'est ce que j'ai mis !?