Discussion :

[DisSsha]

Bonjour,

je suis tombé sur ce lien :

http://binstock.blogspot.com/2008/04/perfecting-oos-small-classes-and-short.html

Etudiant et amateur de programmation orienté Objet, et je me demandais ce que certains programmeur professionnels pensent de ces règles de programmation Objet.

Je commence donc par mon sentiment, pour moi c'est une méthode très instructive, qui a le défaut de devoir faire beaucoup de classes, dont certaines deviennent bateau, de simples conteneurs ... Egalement la regle sur les getter/setter qui me parait assez dure a respecter ( comment faire pour une classe Money, qui possede un attribut int money, si on ne peut ni le set/get ...) et je trouve l'utilisation d'un seul point par ligne totalement extremiste... Cela dit certaines autres regles me séduisent donc je suis dans le flou ..

Et vous vous en pensez quoi ?

EDIT : pour plus de facilité dans le post voici les règles :
1. Use only one level of indentation per method. If you need more than one level, you need to create a second method and call it from the first. This is one of the most important constraints in the exercise.

2. Don’t use the ‘else’ keyword. Test for a condition with an if-statement and exit the routine if it’s not met. This prevents if-else chaining; and every routine does just one thing. You’re getting the idea.

3. Wrap all primitives and strings. This directly addresses “primitive obsession.” If you want to use an integer, you first have to create a class (even an inner class) to identify it’s true role. So zip codes are an object not an integer, for example. This makes for far clearer and more testable code.

4. Use only one dot per line. This step prevents you from reaching deeply into other objects to get at fields or methods, and thereby conceptually breaking encapsulation.

5. Don’t abbreviate names. This constraint avoids the procedural verbosity that is created by certain forms of redundancy—if you have to type the full name of a method or variable, you’re likely to spend more time thinking about its name. And you’ll avoid having objects called Order with methods entitled shipOrder(). Instead, your code will have more calls such as Order.ship().

6. Keep entities small. This means no more than 50 lines per class and no more than 10 classes per package. The 50 lines per class constraint is crucial. Not only does it force concision and keep classes focused, but it means most classes can fit on a single screen in any editor/IDE.

7. Don’t use any classes with more than two instance variables. This is perhaps the hardest constraint. Bay’s point is that with more than two instance variables, there is almost certainly a reason to subgroup some variables into a separate class.

8. Use first-class collections. In other words, any class that contains a collection should contain no other member variables. The idea is an extension of primitive obsession. If you need a class that’s a subsumes the collection, then write it that way.

9. Don’t use setters, getters, or properties. This is a radical approach to enforcing encapsulation. It also requires implementation of dependency injection approaches and adherence to the maxim “tell, don’t ask.”

[Davidbrcz]

Je ne suis pas d'accord avec toutes les règles.

1) et 2) Ses idées sont pas totalement fausses, même si je le trouve un peu trop draconnien. Le but est d'éviter d'avoir 10 niveaux de conditions succesives ou 10 else if qui se suivent. Il faut avoir un bon compris entre longeur des fonctions et quantités de fonctions présentes.

3) En théorie, il a raison. En pratique, faut pas abuser quand même.

4) Autrement dit, on ne devrait pas appeler autre chose que l'interface publique d'un objet: totalement pour.

5) RAS, même si faut éviter les noms de 50 caractères.

6) +1, même si faut savoir adapter la taille des classes au projet en cour.

7) Euh non, pas d'accord. Certaines classes doivent être instanciée pas mal de fois, surtout si les objets ont une courtes durée de vie.

8) Il a pas foncièrement tord mais c'est à voir au cas par cas.

9) +1, on encapsule des comportements, pas des données:
Cf ici.

[Alp]

Bonsoir,

Mon petit avis :

1/ et 2/ Ca ne veut pas dire grand chose. Le principe essentiel en POO c'est 1 classe = 1 responsabilité (dixit Luc Hermitte) ou encore 1 classe = 1 service rendu (dixit koala01).

3/ +1 à David. Mais tu vas pas réécrire une classe pour chaque type primitif... C'est n'importe quoi. A la rigueur, selon le langage, tu peux définir un alias sur ton type (typedef en C & C++ par exemple) pour que ça saute aux yeux, mais bon ...

4/ Pas totalement d'accord. Une bonne hiérarchie d'objets peut avoir de la profondeur, même si les bons frameworks font en sorte d'interconnecter les classes plus intelligemment que ça.

5/ +1 à David.

6/ Encore une fois c'est trop caricaturé... Cf mon commentaire sur 1/ et 2/.

7/ Prenons l'exemple de son type primitif. Si on doit enregistrer un tirage de loto, donc 7 entiers, on fait comment ? On les regroupe deux par deux ? On les regroupe dans une classe ? Non, on est déjà en train de le faire. Et puis même, je sais pas moi des expressions régulières, des chaines de caractères, des objets graphiques, ...

8/ Ca dépend ...

9/ Je dirais d'accord, sauf pour les composants du genre composants graphiques, peut-être.

[gl]

Et vous vous en pensez quoi ?

Comme bien souvent dans ce genre de règle. il part d'un constat bien réel pour aboutir à des règles rigides, arbitraires et pas forcément applicables ni même souhaitables [1].
Pour être bref, je suis d'accord avec l'esprit de ces règles pas avec leur formulation jusqu'au-boutisme : il ne faut pas non plus tomber dans l'exagération.

Plutôt que des règles aussi rigides, il est préférable, à mon avis, de se focaliser sur des grands principes (responsabilité unique, LSP, etc.).



[1] Par exemple, pour commenter la règle 6, je préfère largement une fonction de 51 lignes qui fait une chose et une seule mais entièrement à un découpage artificiel d'une seule fonctionnalité en deux fonctions de 30 lignes ou à une fonction de 25 lignes qui effectue deux traitements.

[el_slapper]

Quand j'ai commençé, je faisais quasiment ça(point 1), dès que je dépassais 2 indentations, je sortais tout ce qu'il y avait dedans. Résultat : un code aussi illisible que du spaghetti non structuré - c'est juste une autre forme de souffrance.

point 2 : je préfère un select case true(bien que celui-ci n'existe pas en Java, il est hyper-pratique en VB et en Cobol) : tous les cas sont nettement identifiés, et on n'imbrique pas de else.

Je suis par contre assez d'accord avec le point 5 : mieux vaut prendre la peine de faire des dénomination verbeuses.

Point 6 : vaste blague. C'est évidemment idéal, mais nous ne vivons pas dans un monde idéal.

En bref, un exercice interessant, mais vite illisible pour le commun des mortels. Une mauvaise idée est une bonne idée que l'on a poussé trop loin.

[kaymak]

Bonjour,

je suis tombé sur ce lien :

http://binstock.blogspot.com/2008/04/perfecting-oos-small-classes-and-short.html

Etudiant et amateur de programmation orienté Objet, et je me demandais ce que certains programmeur professionnels pensent de ces règles de programmation Objet.

Je commence donc par mon sentiment, pour moi c'est une méthode très instructive, qui a le défaut de devoir faire beaucoup de classes, dont certaines deviennent bateau, de simples conteneurs ... Egalement la regle sur les getter/setter qui me parait assez dure a respecter ( comment faire pour une classe Money, qui possede un attribut int money, si on ne peut ni le set/get ...) et je trouve l'utilisation d'un seul point par ligne totalement extremiste... Cela dit certaines autres regles me séduisent donc je suis dans le flou ..

Et vous vous en pensez quoi ?

Ben comme dit dans le billet, ces règles sont là pour se perfectionner par la pratique.
Dans ce cadre là, je les trouvent bien, car contraignantes, elles obligent à faire un effort de réflexion lors de la rédaction.
Effort que l'on ne fait pas toujours par automatisme, flemme ect.

C'est un exercice que je m'appliquerais volontiers un de ces quatre matin, que ce soit pour me perfectionner moi, ou pour améliorer une portion de code bien spécifique et la rendre plus générique.

Dans la pratique quotidienne c'est trop jusqu'au boutiste et n'étant pas guru, je ne m'infligerais pas un tel calvaire dans ma vie de développeur.
Le masochisme n'y est pas de rigueur... Même si la rigueur y est primordiale !

bye

[Luc Hermitte]

Un exercice poussant le vice jusqu'au bout. Pour certains aspects, je l'avais trouvé intéressant.
NB: je ne suis pas un partisan du 100% objet. En fait, je ne suis pas du tout un fanboy OO. Cependant je l'utilise et l'apprécie beaucoup.

1- C'est dans la continuité de "une fonction doit faire une chose, et le faire bien", ou encore "une fonction une responsabilité"
Cette règle ne me choque pas, mais elle est abusée.
Dans les règles qualité du noyau de Linux, Linus (?) a dit un truc comme "if you have more than 3 levels of indentation, you're screwed".
Cela sens le : <<bon, le principe général, c'est une "classe/fonction <-> une responsabilité", comment être sûr que mes petits développeur vont bien l'appliquer, et que mes qualiticiens non experts langage pourront confronter les développeurs cochons? Oh! Je vais contrôler les nombres de lignes/le nombre de niveaux d'indentation/le nombre cyclomatique à une valeur arbitraire!>>

2- Le but est de pousser à utiliser le polymorphisme. Je vois où il veut en venir, mais c'est complètement abusé.

3- C'est abusé de nouveau, mais je comprends la raison à cela. Sans aller jusqu'au type, un typedef est un bon début -- en C++

4- Pour mettre un terme aux appels en chaines et autres abus d'accesseurs.
Pourquoi pas. D'autant que cela permet d'avoir des valeurs intermédiaires nommés et débuggables, et de ne pas oublier certains tests de non-nullité que l'on oublie trop souvent.

5- Ca se tient.

6- concision, concision. Et on recentre les responsabilités. C'est bien.

7- Là, cela m'échappe, il faudrait que je lise Bay si je comprends bien.

8- Et la nouvelle collection métier, on a le droit de la regrouper avec autre chose ? Mal formulé je sens.

9- 100% d'accord. Les accesseurs, encore de temps en temps pour débugger pourquoi pas. Sinon, je ne suis pas fan.
Bref, une règle pour inculquer qu'un accesseur n'est généralement qu'une rupture d'encapsulation, et que cela n'a rien de particulièrement OO.

Sinon, +1 à la remarque de Gilles Louise au sujet de l'importance des grands principes.

Dans le genre "en 10 règles", c'est moins focalisé sur l'enseignement de l'OO: http://www.justsoftwaresolutions.co....able_code.html

[gorgonite]

je pense qu'il faut nuancer la lourdeur de l'encapsulation et du tout objet, lorsqu'on a la chance de bénéficier d'inlining statique, et de suppression de code mort dans le compilo... d'un coup, avoir énormement d'abstraction dans sa conception objet ne sera pas forcemment très chère à l'exécution

[Garulfo]

[...]
9- 100% d'accord. Les accesseurs, encore de temps en temps pour débugger pourquoi pas. Sinon, je ne suis pas fan.
Bref, une règle pour inculquer qu'un accesseur n'est généralement qu'une rupture d'encapsulation, et que cela n'a rien de particulièrement OO.[...]

C'est marrant je n'ai pas du tout compris sa règle 9 dans ce sens là. Pour moi, il dit qu'il ne faut pas utiliser d'accesseur car c'est de la surencapsulation ! C'est pourquoi il dit qu'il est contre les modificateurs et les propriétés. En gros, je pense qu'il encourage le contraire : donner libre accès aux attributs.

Dans ce sens je pense que c'est une bêtise faramineuse qu'il dit. Il réagit comme qqun sur de lui qui n'a jamais de chance de se tromper et qui ne s'inquiète que peu de la modularité à venir. Du moins, c'est ainsi que je le lis.

Si je l'avais lu comme toi je serais d'accord : il faut limiter les accesseurs car c'est un bris d'encapsulation. Mais si on a besoin vraiment d'y accéder, je pense qu'il faut toujours utiliser un accesseur.

En tout cas, qu'en penses-tu ? Car en relisant, j'ai un doute maintenant sur ma manière de le lire.

[Luc Hermitte]

Effectivement. C'est à ce demander comment il perçoit la chose. Tandis que j'ai une vision qui vois les accesseurs, et plus particulièrement les mutateurs, comme de la décapsulation (désolé pour le néologisme)

Toutefois, le "tell, don't ask" me parait rejoindre mon plus gros reproche envers les accesseurs : on n'a pas confiance aux "sous-"classes et au lieu de leur confier des responsabilités, on s'empare de leurs attributs pour faire des choses avec (d'où le "décapsulation"). Une approche de control-freak à l'"ancienne".

Ensuite, comme je le disais au début de mon intervention, je ne suis pas un fanboy OO. Si j'ai une classe qui doit exposer des données, si je n'ai pas des histoires d'immuabilité, ou de contraintes à faire respecter, je ne m'embête pas avec des accesseurs.
Quitte à devoir refactorer, je préfère passer un peu de temps dessus à faire le tour des endroits impliqués et m'assurer de ne pas être passé à côté d'un détail d'importance. Un programme qui ne compile pas est un bon moyen pour passer le temps qu'il faut à faire le tour de tous les points d'utilisation.