Reprise du message précédent :
c'était juste pour souligner le coté absurde de la réflexion de Smaragdus qui disait que les interfaces n'étaient là que pour pallier au manque d'héritage multiple. si vraiment c'était le cas, pourquoi un langage comme C#, sorti bien après Java, ne supporte pas l'héritage multiple ?
l'héritage multiple, pour aussi pratique qu'il soit, amène aussi son lot de soucis, et c'est pour ça que Java ou C# ont fait le compromis de supporter les interfaces à la place. dire que les interfaces sont là pour pallier au manque d'héritage multiple est une connerie sans nom

Parce que tu ne fais jamais appel à super?   Mais c'est quoi ces programmeurs du dimanche?!

En tout c'est moins une connerie que de vouloir définir un constructeur dans une interface

appeler le super d'une interface ?
 
Mais LOL quoi Arrete la drogue  

Qui a parlé de faire un constructeur dans une interface? Je disais justement que c'est l'une des choses qui différencie les interfaces des classes abstraites.

Et c'est bien la raison pour laquelle ça a été inventé en Java, il fallait une manière de supporter les avantages de l'héritage multiples (qu'un objet donné puisse implémenter un nombre illimité de types) sans en avoir les inconvénients potentiels (configurations en diamant par exemple).

Parce que (comme d'hab) l'expérience liée au C++ a été si mauvaise que les dissaïdors et pas mal de développeurs en ont pris peur tout simplement.
 
Le C# n'a jamais été là pour être une percée fantastique dans le monde de la programmation, il était là pour ramener dans le giron microsoft les programmeurs java.

Ils ont décidé de ne pas en avoir les inconvénients, mais en ont voulu les avantages, d'où l'invention des interfaces (note: des langages comme Smalltalk ou Ruby n'ont pas d'héritage multiples mais n'ont pas non plus d'interfaces, nécessaires uniquement dans le cas de langages typés statiquement et explicitement).
 
Les interfaces sont donc bel et bien apparues pour pallier au refus d'implémenter les interfaces, de même que le concept de Mixins dans d'autre langages (comme le ruby).

Retourne te coucher, t'as toujours pas compris de quoi on parlait.

On est d'accord, je parle bien du refus d'implémenter l'héritage multiple (je suppose que c'est de ça dont tu voulais parler), et non de l'absence d'héritage multiple au moment de la création du langage. La nuance est là.

 
parce que c'est un langage "newbie friendly" ?    

k, lol

Mouais, je vais accepter mais tu chipottes, ils ont refusé d'implémenter l'héritage multiple (pour ne pas en subir les inconvénients -- indéniables), donc l'héritage multiple était absent, donc il leur fallait un mécanisme capable de cloner partiellement les avantages de l'héritage multiple (là encore de même pour les mixins, à la nuance près que les mixins se concentrent sur l'implémentation alors que les interfaces se concentrent sur... l'interface...)

De toute façon, l'héritage ça pue, Decorator roulaize
 
(ceci était un post purement inutile, merci de votre attention)
 
---> []

Decorator ne change pas le type d'un objet et ne lui ajoute pas de types
 
À part ça on sait effectivement depuis 87 que la délégation automatique est une alternative viable à l'héritage multiple...
 
Pas de bol, c'est pas faisable en java

C'est bien pour ça que j'ai dit que c'était un post inutile

private BddUpdater bdUpdater; // BddUpdater est une interface
(...)
// puis l'utilisateur choisit la base à updater. une fois qu'il a choisi, je créé mon BddUpdater :
if (option.equals("Access" )) {
    bdUpdater = new AccessUpdater(this);
} else if (option.equals("Oracle" )) {
    bdUpdater = new OracleUpdater(this);
}

En faite, ce que je comprend c'est qu'au moin les methodes present dans l'objet bdUpdater sont garantie sur facture parce qu'elle certifié-conforme par une interface donc pas de surprise pour la suite.
Un factory c'est quoi ? (entre temps je cherche de mon coté)
 

ok je m'en doutais un peut sinon cela aurait été un peut trop restrictif mais pourquoi pas.

up up pour la factory j'ai cherché mais j'ai eu une vague explication disant comme quoi c'est une classe qui permet de générer une classe type. Un truc dans le genre.

C'est un Design Pattern du GoF (deux en fait, Abstract Factory et Factory Method, vu la discussion il parlait d'Abstract Factory).
 
Tu peux en trouver une explication ici mais celles du GoF ou de Head First Design Patterns sont mieux.

Factory, c'est un design pattern dont le principe est de déporter dans une classe à part l'instanciation d'objets implémentant la même interface (je simplifie à mort hein)
Ainsi dans le cas de mon exemple, créer un factory qui me renvoie l'objet créé en fonction du choix de l'utilisateur permet de centraliser cette création, et ainsi, le jour ou je voudrais supporter d'autres SGBD, je n'aurais qu'à rajouter qu'un seul test dans mon factory, qui me renverra de toute façon un BddUpdater. Ca permet d'éviter de toucher au code métier, facilitant ainsi la maintenance (imagine que la création d'un nouvel updater se fasse à plusieurs endroits du code : sans factory, le jour ou je veux supporter un nouveau SGBD, je dois rajouter ledit SGBD à chaque fois que je fais le genre de test de mon code)
 
http://gsraj.tripod.com/design/cre [...] ctory.html

La diférence entre une classe abstraite et une interface?
Quand tu hérite d'une classe abstraite, tu n'est pas obligé de recoder toutes les procédures et fonction de la classe abstraite ce qui fait que tu peux te retrouver avec des procédures et fonctions qui ne font rien du tout surtout si la classe abstraite évolue ultérieurement.
 
Par contre, avec une interface, t'es obligé de recréer toutes les procédures et fonctions indiqué dans l'interface et si l'interface évolue, le compilateur te gueulera dessus si tu n'as pas mis à niveau toutes les classes qui en héritent. Pour le développeur, c'est beaucoup plus sécurisant vu qu'il sera sur de ne pas en oublier et ce même si du coup il lui faudra quelques minutes de codage de plus pour que le programme compile complétement.

mmmhh je commence à saisir surtout grace à ton exemple. Elle permet de servir de cible pour d'autre classe en gros pour une demande d'opération particulière.
En faite, il y a pas de syntaxe particulière c'est juste dans la conception des classes que nous pouvons faire un factory.

j'aime les postafloud

Tu pourrais lire le topic avant de répondre la prochaine fois

Masklinn > Je l'ai lu et je n'ai rien vu qui donne des arguments pour l'idée inverse.

On va faire un truc:
 
Tu prends ton éditeur de fichier préféré tu crées un fichier AbstractFoo.java contenant

public abstract class AbstractFoo {
    public abstract void abstractFoo();
    public abstract void abstractBar();
    public abstract void abstractBaz();
}

tu compiles, tu crées un autre fichier Foo.java contenant

public class Foo extends AbstractFoo {
}

tu tentes de compiler et tu regardes ce que ça donne ok?
 
Ensuite tu crées IFoo.java

interface IFoo {
    void abstractFoo();
    void abstractBar();
    void abstractBaz();
}

tu compiles, tu modifies Foo pour implémenter IFoo au lieu d'étendre AbstractFoo, tu tentes à nouveau de le compiler, et tu compares le message à ce que t'avais juste avant (tu peux même differ entre les deux si ça t'amuse)
 
Enjoy

C'est cencé faire quoi?  parce que ce que dit omega2 ne me parait pas faux par rapport au explication précédement indiquées.

c'est censé faire exactement pareil.
 
Sinon interessant le factory, mais y a un truc que je comprends pas : puisqu'il faut passer un paramètre au factory, qui lui permettra de choisir la classe à instancier, le jour où tu veux rajouter un nouveau module, il faudra de toute façon reprendre chaque endroit faisant passant ce paramètre au factory.
 
J'en viens donc à me dire que ce paramètre doit être passer au factory à un seul et unique endroit (par exemple le frontcontroller). Vous voyez les choses comme moi ?

tu fais passer en paramètre le nom de l'updater à créer, tu n'as rien à faire d'autre.
 
un exemple de Factory "tout con" et basique qui pourrait éventuellement convenir à mon bousin :
 

public class BddFactory {
    public BddUpdater createUpdater(String sgbd)
    {
        BddUpdater updater = null;
        if (sgbd.equals("Access" )) {
            updater = new AccessUpdater();
        } else if (sgbd.equals("Oracle" )) {
            updater = new OracleUpdater();
        }
        return updater;
    }
}

 
puis le code client :

factory = new BddFactory();
bdUpdater = factory.createUpdater(option);

Si dans mon code je voulais gérer un updater pour une base MySQL par exemple, tout ce que j'aurais à faire, c'est de coder la classe MySQLUpdater, et rajouter un test supplémentaire dans le factory, sans toucher au code client. Ce qui n'était pas le cas dans mon exemple précédent.
 
Ceci est le cas le plus simple de Factory. Après tu as d'autres variantes plus complexes mais qui permettent carrément de personnaliser chaque code client, etc...

vive les templates!

que viennent foutre les templates là dedans ?

oui je vois pas trop le rapport
Ce monsieur peut il nous donner une explication ?

@Harkonnen : ça j'ai bien compris
mais ton :  

le jour ou tu veux une nouvelle base, il faut reprendre tous les endroits de ton code où tu as cette ligne pour mettre l'option que tu veux. Et ça c'est casse-couille.
 
J'en venais donc à me dire que ce parametre passé au factory, ne doit l'être qu'a un seul endroit de ton code (comme ton frontcontroller), sinon c'est à chier.
Vous verriez ça autrement vous ?

je te suis pas là... l'option est choisie par l'utilisateur, donc si un jour l'utilisateur veut du MySQL, j'ai pas à toucher à cette ligne vu que bdUpdater référence une interface (BddUpdater) et non une classe concrète !
tout ce que j'ai a faire, c'est m'assurer que ma classe MySQLUpdater implémente bien l'interface BddUpdater

oui c'est la valeur d'un parametre à rajouter donc ça reste toujours souple pas besoin de modifier à chaque endroit qui font appelle a cette methode pour gerer un autre sgbx.
bien evidement il est préférable de ne peut pas placer une valeur en dure dans le parametre.

Je te parle du cas où c'est un choix d'implémentation, pas un choix utilisateur.
 
L'utilité du factory, c'est de ne pas avoir à retoucher ton code métier le jour où tu dois changer de base (par exemple).
Ton factory, pour savoir s'il doit instancier une classe qui se connecte à une base MySQL, ou une classe qui se connecte à une base oracle, faut bien lui dire.
 
Donc tu lui passes un paramètre à ton factory (logique). Le problème étant : si tu passes ce paramètre à ce factory un peu n'importe où, le jour où tu changes de base de données tu l'as dans le cul. Il faudra modifier ce paramètre partout où c'est nécessaire.
 
Et donc je me disais que le paramètre passé au factory, qui lui permet de savoir quelle classe instancier, il fallui lui passer à un seul endroit de ton code, et je demandais donc (pour la 3eme fois ) si vous voyez les choses comme moi.
 
edit pour au dessus : si par exemple, dans chaque classe qui font appel à la base de données, tu passes ce paramètre au factory pour avoir l'objet BDD, bah le jour où tu changes de base, tu vas reprendre chacune de tes classes qui font appel à la base de données ... Paramètre ou pas, ça reste un truc de merde à changer partout dans ton code. DOOOOOOOONNC, je pense qu'il faut que ce paramètre ne passe qu'à un seul endroit.

C'est valable si le type de sgbd (variable option) est définit en dure mais cela depend d'ou provien la source. Elle peut venir d'une liste déroulante ou autre donc pas de souci. La factory est bien la pour permettre de faire un switch sur différent sgbd c'est pas figé.

mais je n'y touche pas au paramètre, c'est l'utilisateur qui le choisit, par le biais d'un combobox !
je récupère dans une variable le texte courant du combobox, que je transmet en paramètre au factory, rien de plus

Ca fait exactement la même chose

omega2 a dit que les interfaces étaient fondamentalement différentes des classes abstraites, que le compilo gueulait si tout n'était pas implémenté etc.
 
Il avait été expliqué avant même son post par skeye dès le 8e post du topic que l'interface est un cas particulier des classes abstraites (classes abstraite sans membres dont toutes les méthodes sont abstraites), mon post avait simplement pour but de le démontrer à omega2, et donc de lui expliquer que la distinction qu'il effectue est totalement fausse (à tel point qu'en java le message d'erreur est le même à la virgule près. De là à penser que les interfaces font usage de classes abstraites pures au niveau de leur implémentation et que la distinction est totalement arbitraire, il n'y a qu'un pas que je franchis allègrement)
 
Et arrêtez de parler de factory quand vous parlez de Factory method (ou même de SimpleFactory en fait, là), Factory ça peut désigner 3 trucs extrèmement différents donc c'est lourd

Vas acheter et lire Head First Design Patterns, il explique très bien ces choses là.

ok je rentre pas dans les factory s'il y en a de toute sorte et que chacun cherche a expliquer l'une d'elle sans le préciser

Djebel1 > Un truc génial dans beaucoup de langages objets, c'est le transtypage. En gros, t'as bien une classe BDDMysql et une BDDPgSQL mais tout ce que véront les autres classes, c'est par exemple des objets de type BDDGenerique. (ou BddUpdater)
Le langage fournira donc l'accés aux fonctions existant dans la classe générique et la fonction exécuté sera bien celle de la classe réelle de l'objet et pas celle de la classe "présumé" par les autres classes.
Evidement, ca ne marche que si les fonctions ont les même nom et les même paramettre.
 
EDIT : Masklinn > Comme tu viens de le citer, l'interface est équivalent à un cas particulier des classes abstraite. Ca n'est donc pas la même chôse. Ca serait comme dire qu'un avion est un cas particulier de véhicule à moteur donc c'est la même chôse.

bah vi mais donc si ce n'est pas au choix de l'utilisateur ? N'est-il pas méga préférable de savoir exactement où le fameux paramètre est définit ? Et donc de ne le définir que à un seul endroit
(je pense au cas où tu n'accèdes qu'à un seul type de bdd dans ton projet, mais que tu veux permettre d'en changer facilement).
 

tu nous ferais pas un topo succint ?
 

arf, acheter
 

Raté, le truc génial c'est le polymorphisme pas le transtypage
 
Et c'est pas dans "beaucoup de langages objets", un langage objet sans polymorphisme c'est pas un langage objet, le polymorphisme fait partie des bases du concept de POO

Tu racontes vraiment n'importe quoi
 
C'est même plus de la mauvaise foi à ce niveau, on est à la limite de la stupidité, et ce sans même parler de ton analogie n'ayant strictement aucun rapport avec le cas qui nous occupe
Et vu que j'ai le contenu de ton post avant édition, je vais y répondre

Vu à quel point le java est verbeux en l'état, je dirais que ça n'a aucune importance, sans même mentionner le copier-coller ou les abbréviations, disponibles dans 90% des éditeurs de textes utilisables.

C'est jamais que ce qu'on explique depuis 2 pages hein

C'est pas le cas, apprends à lire bon sang

Raté, apprends à coder
 
Que tu le veuilles ou non, le rôle des interfaces n'est ni plus ni moins que le moyen de bénéficier de la fonctionalité "héritage du type" issu de l'héritage multiple en C++ et indisponible en Java/C# du fait du désir de ne pas implémenter le dit héritage multiple

Si je pense à rentrer chez moi ce soir et que je suis pas trop crevé, peut-être.

Pour pas mal de choses, les meilleures sources en info sont des bouquins
 
Les Design Patterns en font partie