Discussion :

[TiranusKBX]

Je suis d'accords, les pavés nécessitant 15 minutes de lecture c'est rebuttant

[foetus]

C'est totalement le double en CPU et 70mega en mémoire de plus alors que dans tous les cas les données contenus sont les même dans chaque objet des deux cas.

J'attends un expert qui me contredise, mais pour moi c'est logique
Tu as 5 000 000 recopies dans ta version 2 qui reste en mémoire.

De plus sortir du Java pour faire cela, mais en C++ [que je connais mieux], nous avons les "smart pointers", les "lazy initialization", le "reference counting", ...
Tu sais en C++ on peut créer un objet avec un new et propager son pointeur "brut" dans plusieurs objets qui ne font que le "consulter"
Un truc de fou

[la.lune]

J'attends un expert qui me contredise, mais pour moi c'est logique
Tu as 5 000 000 recopies dans ta version 2 qui reste en mémoire.

Dans les deux cas je n'ai rien détruit, et même si je l'avais fais pour les deux cas la méthode runtime.totalMemory() garde toute la mémoire alloué par la machine virtuelle Java, moi ça ne m'interresse pas de détruire quoi que se soit, au contraire je veux savoir combien mes objets ont forcés la JVM à allouer de la mémoire.

Quand on lance le programme runtime.feeMemory() garde la mémoire libre pour les objets déjà crées, et j'ai récupéré le runtime avec Runtime.getRuntime(); alors runtime.feeMemory()==runtime.totalMemory(), enfin presque , mais après je commence à créer des objets c'est la mémoire totale du JVM qui augmente, moi je veux juste savoir combien j'ai poussé la JVM à créer c'est tout, tu ne m'a vu nulle part détruire quoi que se soit.

C'est simple vas y code nous un programme pareil en C++, si j'ai le temps je vais le faire mais si tu trouve que ce que j'ai fais ne te convainque pas prouve nous le contraire, et poste le code ici, on a là où tester.

[jnspunk]

Pourquoi les développeurs ne réutilisent pas le code existant ?
- Le chef de projet n'informe pas les développeurs du code existant, car lui même l'ignore ou connait mal les technologies utilisées.
- Les développeurs ne peuvent pas exploiter le code existant à cause des dépendances, librairies, accès refusé, etc...
- La conception du code ne prenait pas en compte sa réutilisation.

Pourquoi les développeurs ne codent pas de manière à réutiliser le code ?
- Le directeur technique demande à un développeur(et payé comme tel) le travail d'un concepteur,
ignorant la conception le développeur donne le "travail" aux autres développeurs,
puis dans l'équipe qui prend en compte la réutilisation du code?
- Le chef de projet donne au compte goutte les informations aux développeurs et le code ne peut se réutiliser lorsqu'on le conçoit sans vues d'ensemble.
- Quand le Chef de projet utilise le travail des développeurs comme brouillon puis changent du jour au lendemain les cas d'usages à développer, la volonté de réutilisation du code en pâti.

Un bon séjour en SSII française lui ferait du bien.

[pcaboche]

Mais comment oser dire ça alors que sur le tas on a deux objets à chaque création d'un objet, c'est deux objets en double par rapport à l'héritage qu'on aurait un seul, même si les contenus sont identiques en état, ce qui fait que l'association/agrégation contribue à une perte de mémoire et du temps CPU.

Dans bien des cas, un Composite ou un Décorateur, ça permet d'avoir beaucoup plus de flexibilité qu'en multipliant les classes à gogo.

En tous cas c'est comme ça que je comprends foetus quand il parle d'association / agrégation / composition.

C'est totalement le double en CPU et 70mega en mémoire de plus alors que dans tous les cas les données contenus sont les même dans chaque objet des deux cas.

En Java (si je me souviens bien), un objet occupe au minimum 8 octets en mémoire (l'overhead: contient des informations servant à déterminer le type d'objet) auquel s'ajoute la taille des données qu'il contient. Un objet sans propriétés pèse donc 8 octets.

Dans ton cas, tu as beaucoup d'objets avec peu de données dedans, donc c'est normal que tu aies une telle augmentation de mémoire. Si tu as des objets avec plus de données dedans, le rapport (taille de l'overhead ) / (taille totale) devient beaucoup plus faible, voire négligeable.

En gros, ce que tu mesures, c'est plus ou moins la taille de l'overhead des objets en Java.

[el_slapper]

(.../...) Même si, quelque soit le langage, rendre un code réutilisable est toujours plus long que de le faire rapidement juste pour soi.
(.../...)

Je ne suis pas du tout d'accord avec le reste, mais au final, c'est ce petit bout là qui est important - et je suis 100% d'accord. Faire du réutilisable, c'est un boulot supplémentaire. Qu'on soit en objet ou pas, d'ailleurs. Boulot en terme de codage, mais surtout en terme de validation. Si, pour des raisons tactiques ou stratégiques, on décide qu'on en a pas besoin, alors ça n'est pas fait - et ça ne sera jamais fait, et on se retrouve avec des duplications eternelles.

Entre le chef qui veut tout pour avant-hier sans faute, et le programmeur qui n'a pas forcément envie de se rajouter du travail pour une fonction(ou classe, ou autre) qu'il ne va peut-être jamais réutiliser, la pente est rapidement glissante.

[la.lune]

Dans bien des cas, un Composite ou un Décorateur, ça permet d'avoir beaucoup plus de flexibilité qu'en multipliant les classes à gogo.
En tous cas c'est comme ça que je comprends foetus quand il parle d'association / agrégation / composition.

Moi je parle des principes de base de la POO et vous me parlez de patterns données.
Comment peux-tu faire du Composite ou Décorateur sans l’existence du concept de base de l'héritage en POO, IMPOSSIBLE!!!! Tous ces deux patterns mélangent entre Héritage et agrégation/composition.

Dans l'un le parent accepte une liste des fils et l'autre le décorateur décore un seul composant à là fois et on peut enchaîner récursivement vu que le décorateur lui même est un composant.
Dans tous les deux cas parent/fils décorateur(+décorateur concret)/décoré héritent de composant. Donc impossible de faire quoi que se soit sans le concept d'héritage.

Mon objectif c'est de mesurer les deux concept de façon brut indépendamment d'un cas donné, et je n'ai pas dis qu'il faut multiplier les classes abondamment, chaque chose doit être utilisé à sa place.

Et foetus ne me parle pas de pattern là, mais de relation entre objet(association / agrégation / composition)

Dans ton cas, tu as beaucoup d'objets avec peu de données dedans,

Le pus important se ne sont pas les données, dans tous deux cas tous les objets contiennent des données identiques, tout ce que je peux faire avec l'un je peux faire avec l'autre une fois mes objets crées, dans chaque cas si j'affiche toute la liste j'aurais la même affichage.

Mais utiliser un concept dans un endroit qui n'est pas sa place est un catastrophe.

[Traroth2]

Bon, ce que je vais dire, c'est un peu de la provocation, mais il y a aussi un nombre de cas non négligea&ble où on a de la réutilisabilité inutile. On conçoit l'APi de la mort, on brainstorme comme des fous pour avoir un fonctionnement modulaire, des façades et tout le toutim. Mais le truc, c'est que ce que fait le composant n'a pas d'intérêt dans un autre contexte, et il n'est tout simplement jamais réutilisé. Concevoir du code pour qu'il soit réutilisable a un coût, comme tout. Il faut quand même se demander à un moment si la réutilisabilité a vraiment un intérêt.

[la.lune]

Tu sais en C++ on peut créer un objet avec un new et propager son pointeur "brut" dans plusieurs objets qui ne font que le "consulter"

Tu fais comme si on ne peut pas faire ça en Java, en Java les références des objets ne sont pas traités comme sont traités en C++, en C++ si on appel l'opérateur d'affectation sur une référence il appel un constructeur de copie par défaut, donc création d'un nouveau objet. Ce n'est pas le cas en java, on manipule les références des objets comme les pointeurs en C/C++. Avoir une référence je peux la passer à plusieurs objets sans que l'objet soit recréé.

Mais déjà ce que tu viens de dire là, montre que tu ne sais même pas bien définir l’extension que tu veux, là tu me parles de relation un à plusieurs ou plusieurs à un.

Là je souligner à pcaboch et à toi aussi que si par exemple je comparais entre le fait de considérer un état unique d'un objet mère devant plusieurs objets fils par agrégation d'un côté et l'héritage d'un autre côté c'est un autre cas, là on allait parler du contenu des objets.

Si je fais par exemple pour le cas de l’agrégation:

Code Java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
         List<ExtMClass> list=new ArrayList<>();   
        MClass monObjetRef=new MClass(2000);
        for(long i=0; i<=5_000_000;i++){
        list.add(new ExtMClass(monObjetRef,i*10));
        }

Là je passe juste la référence à tous les autres objets qui contiennent l'objet étendu.
Et pour l'héritage je serais obligé de faire :

Code Java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
List<ExtMClass> list=new ArrayList<>(); 
          for(long i=0; i<=5_000_000;i++){
        list.add(new ExtMClass(2000,i*10));
        }

Bon dans ce cas j'ai pour le premier cas(extension par agrégation)

Memoire utilisé:153 mb
Le temps écoulé: 1s

Pour le 2e cas(extension par héritage):

Memoire utilisé:154 mb
Le temps: 1s

Donc égaux en CPU et presque égaux en mémoire(là je néglige les millisecondes et les Ko donc il y a arrondissement)

Et pourtant je suis totalement d'accord si l'objet mère possédait plus de données, donc négligeable devant la taille de l'overhead des objets, c'est sûr que l'héritage est mal placé dans ce cas de relation un à plusieurs, et elle n'a pas sa place ici.
Prenons cet exemple j'ajoute ces attributs à la classe mère:

Code Java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
protected long a; 
protected long b; 
protected long e; 
protected long f; 
protected long g; 
protected long i; 
protected String nn;
protected String bb;
protected String cc;
protected String ee;

Je génère le constructeur et tous les getters et setters, et j'ajoute d'autres attributs aux classes qui étendent

Code Java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
long c; 
long h;
String ii;
String oo;
String pp;

Pour le premier cas d’agrégation je fais en bref ceci dans main en réduisant un peu la barre de 5millions à 2millions car j'ai une une exception de dépassement de l'overhead

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 MClass monObjetRef=new MClass(1000,1000, 1000, 1000, 1000, 1000, "Toto", "Tata","Tataou", "Tataa");
        List<ExtMClass> list=new ArrayList<>();   
        for(long i=0; i<=2_000_000;i++){
        list.add(new ExtMClass(monObjetRef,i, i+1, "Toto"+i+2, "Tata"+i+3, "Titi"+i+4));
        }

Le 2e cas d'héritage bien sur que les données de la partie mère est identique

Code Java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
List<ExtMClass> list=new ArrayList<>();   
        for(long i=0; i<=2_000_000;i++){
        list.add(new ExtMClass(i, i+1, "Toto"+i+2, "Tata"+i+3, "Titi"+i+4, 1000,1000, 1000, 1000, 1000, 1000, "Toto", "Tata","Tataou", "Tataa"));
        }

Après avoir fais plusieurs testes sur cette grande quantité de données j'ai pour le premier cas(agrégation)

Memoire utilisé:421mb
Le temps écoulé: 6 s

Pour le 2e cas

Memoire utilisé: 573 mb
Le temps écoulé: 5 s

J'ai une perte de 152Mega bit pour rien avec l'héritage et pourtant en temps CPU ils sont presque égaux car les opérations à réaliser sont presque les même il n'est pas obligé de créer deux objest toujours et en CPU on voit l'héritage est un tout petit peu mieux. Mais le plus important c'est la mémoire, pourquoi dupliquer les données là où il faut juste une relation d’agrégation.

En fait je voulais donner une réponse au troll foetus sur l'héritage comme quoi il bouffe de la mémoire et du CPU, ce sont les moches conceptions qui bouffent le CPU et la mémoire.

[blbird]

Bon, ce que je vais dire, c'est un peu de la provocation, mais il y a aussi un nombre de cas non négligea&ble où on a de la réutilisabilité inutile. On conçoit l'APi de la mort, on brainstorme comme des fous pour avoir un fonctionnement modulaire, des façades et tout le toutim. Mais le truc, c'est que ce que fait le composant n'a pas d'intérêt dans un autre contexte, et il n'est tout simplement jamais réutilisé. Concevoir du code pour qu'il soit réutilisable a un coût, comme tout. Il faut quand même se demander à un moment si la réutilisabilité a vraiment un intérêt.

Entièrement d'accord. J'ai déjà vu (surtout en Java), des "architectes" pondre des applicatifs J2EE en 5 ou 6 couches, sans qu'il n'y ait aucun intérêt, et je dis bien aucun, à ce nombre de couches. Résultat : pour modifier un comportement dans un écran, il fallait modifier 5 fichiers différents...

Posez-vous la question des architectures multi-couches, qui rajoute, quoi qu'on en dise, de la complexité au développement, au débogage, et même des fois à l'utilisation : combien de fois l'intérêt d'avoir rendu les couches indépendantes, à savoir la possibilité de changer l'une sans trop impacter les autres, a réellement été utilisé?

Tout est une affaire de juste milieu : adapter son développement aux besoins présents, certes, mais aussi futurs.

[moldavi]

Bonjour.

En fait il n'y a aucune limitation dans la réutilisation en POO.

Le débat a dévié sur le développement de bibliothèque et j'ai fait cette erreur. Développer des bibliothèques n'a rien à voir avec la réutilisation en POO.

Juste un exemple. Je développe une classe en C++ pour la gestion de l'Oculus Rift http://fr.wikipedia.org/wiki/Oculus_Rift. Cette classe a trois fonctions, une pour l'initialisation, une pour la libération de ressources, et une pour obtenir les données des capteurs.

Je peux utiliser cette classe dans n'importe quel programme sans la re-coder. C'est une boîte noire qui fait son travail. La réutilisation en POO bat son plein ici. Grâce à l'encapsulation, je déclare une classe, j'appelle trois fonctions, et c'est terminé.

Il y a clairement confusion entre développer une bibliothèque qui fait le café, et la réutilisation en POO.

[Cyrilange]

J'ai créé mon propre "Framework" dans lequel j'ai tous les codes que je réutilise. Sans parler des templates pour les interfaces que je réutilise également sous Visual Studio 2012. Donc je ne me sent pas concerné par cet article, même si il est toujours possible de faire mieux pour éviter la redondance.

[Mat.M]

Réutiliser nécessite un gros travail d'abstraction, de découpage et de nommage. Il faut tirer l'essence d'un bloc de code pour mettre un nom précis et adéquat dessus et lui donner un contrat clair, éventuellement distinguer ses différentes responsabilités pour les extraire dans des éléments séparés... C'est une des choses les plus compliquées en programmation.

c'est exact...et pour dévier du sujet principal j'ai l'impression que dans la majorité des projets informatiques en France il y a un manque flagrant de personnes sachant construire une bonne architecture de projet informatique.
S'il y a des projets qui échouent c'est partiellement à cause de cela...

J'ai créé mon propre "Framework" dans lequel j'ai tous les codes que je réutilise. Sans parler des templates pour les interfaces que je réutilise également sous Visual Studio 2012. Donc je ne me sent pas concerné par cet article, même si il est toujours possible de faire mieux pour éviter la redondance.

c'est une très bonne initiative mais l'inconvénient de cela c'est qu'en milieu professionnel, si un projet utilise ton Framework et si tu quittes la boite, il faudra que la personne qui te succède puisse maintenir ton code

Posez-vous la question des architectures multi-couches, qui rajoute, quoi qu'on en dise, de la complexité au développement, au débogage, et même des fois à l'utilisation : combien de fois l'intérêt d'avoir rendu les couches indépendantes, à savoir la possibilité de changer l'une sans trop impacter les autres, a réellement été utilisé?
Tout est une affaire de juste milieu : adapter son développement aux besoins présents, certes, mais aussi futurs.

tout à fait d'accord
Ce que tu décris c'est ni plus ni moins "monter une usine-à-gaz" avec différentes couches logicielles
il faut trouver le juste milieu
Mais j'ai l'impression que nombres de projets informatiques sont bâtis comme tu le décris avec différentes couches...

[DonQuiche]

J'ai créé mon propre "Framework" dans lequel j'ai tous les codes que je réutilise. Sans parler des templates pour les interfaces que je réutilise également sous Visual Studio 2012. Donc je ne me sent pas concerné par cet article, même si il est toujours possible de faire mieux pour éviter la redondance.

La question n'est pas de savoir si la réutilisabilité est possible dans certains cas mais ce qui la limite dans les autres. Si tu ne te sens pas concerné c'est uniquement par manque d'expérience.

[eskatos]

La POO nous a promis la réutilisation mais comme expliqué plus haut par d'autres membres, beaucoup d'obstacles existent.

Depuis plus de 5 ans je suis tombé dans la programmation orientée composite, COP.
Ceci va au delà de la POO et nécessite que le langage utilisé propose certaines fonctionnalités et de la rigueur du développeur.

C# et Scala sont de bons candidats mais le cadre reste flou.

Pour Java il y a Qi4j qui apporte une programmation orientée composite très complète : http://qi4j.org/

[foetus]

Depuis plus de 5 ans je suis tombé dans la programmation orientée composite, COP.

Tiens un truc à regarder

J'avais déjà du mal avec la POA (Programmation Orientée Aspect)

[DonQuiche]

Pour Java il y a Qi4j qui apporte une programmation orientée composite très complète : http://qi4j.org/

De ce que je comprends il ne s'agit que de mixins ? Qui sont effectivement une très bonne chose mais de là à créer un nouveau terme...

[foetus]

En tous cas c'est comme ça que je comprends foetus quand il parle d'association / agrégation / composition.

Je pensais à cette lecture (un peu longue certes)

Parce que la.lune n’arrêtait pas de répondre à chaque message par "POO = héritage == réutilisation POWA"

Alors que, je pense, que la POO a été créée dans un premier temps pour grouper les traitements en ajoutant un/ des état(s).
Et ceci afin de faciliter la conception (d'autres intervenants l'ont dit) [même si ce n'est pas toujours vrai]

Et je reprends mon exemple des frameworks/ librairies qui permettent aussi la réutilisation [mais un peu artificielle]
Mais toujours à l'expérience et au même domaine près.

Par exemple: une société qui fait que des applications iPhone/ iPad connectées va, au bout de 2 ou 3 applications, pouvoir extraire la colonne vertébrale des applications. Et par la suite, n'avoir qu'à modifier les écrans, rebrancher les appels externes et 2-3 trucs mineurs.
Et mettre un stagiaire, mais c'est une autre histoire

Tout cela, parce que l'API Apple est très bien et le permet.

[matthius]

Les outils RAD améliorent le polymorphisme de la POO.
Il faut éviter les copiés-collés, mais pour les éviter il faut connaître l'évolution, la structure et l'objectif des composants, ce qu'on ne m'a jamais expliqué.

[Carhiboux]

L'abus de réuse... ça fait des kangourous tueurs!