Hello Steeven,

Je vais citer l'article de William Durand:
"Object Calisthenics are programming exercises, formalized as a set of 9 rules invented by Jeff Bay in his book The ThoughtWorks Anthology. The word Object is related to Object Oriented Programming. The word Calisthenics is derived from greek, and means exercises under the context of gymnastics. By trying to follow these rules as much as possible, you will naturally change how you write code. It doesn’t mean you have to follow all these rules, all the time. Find your balance with these rules, use some of them only if you feel comfortable with them." - William Durand williamdurand.fr/...

Les règles sont effectivement difficiles à suivre dans la vie réelle sur tout une base code de production, cependant, c'est un bon exercice pour se rappeler d'éviter certaines mauvaises habitudes.

Ca peut-être un challenge qu'on se donne avec son pair pour certaines features, tout comme se dire qu'on essai de développer une feature en utilisant les paradigmes fonctionnels :p

Hello Cédric ^^,

Pour ma part je trouve que la plupart sont assez simple a suivre, la plus dure serait pour moi les classes de 50 lignes maximum!
Et ensuite :
No classes with more than two instance variables.
No getters or setters.

Un collègue m'a dit que pour lui c'était une "reformulation assez précise des principes Clean Code avec une pointe de DDD".

Je suis assez d'accord dans le sens ou ça permet d'avoir un code lisible ou on capte l'intention et où chaque méthode à un seul niveau d'abstraction à la lecture.

J'ai voulu partagé car, je n'ai malheureusement pas souvent vu du code qui se lit comme "well-written prose" (pour citer Uncle Bob); et je pense qu'en suivant ces quelques règles ça pourrait aider.

Je ne connais pas bien les paradigmes fonctionnels , il faudrait que je liste la ressource : compagnon.artisandeveloppeur.fr/....

Hello Steeven,

Je suis d'accord avec toi et ton collègue sur le fait que c'est un superset de règles allant dans la direction des principes Clean Code.

Quand je parle de vie réelle, je parle de code d'entreprise. La ou dans un exercice, les règles sont données par le contexte de l'atelier, dans un contexte d'entreprise, les règles sont données par le métier.

Je me vois difficilement dire à un expert du domaine, désolé votre dossier (agrégat) ne peut pas "contenir" un client en plus, car il y a déjà un deux référence vers d'autres instances (produit, etc.).

Aussi, ce qui concerne la lisibilité, il faut faire attention. Quand je lis un livre, il n'est pas coupé en plein de petits bouts de papier (fichiers). Je me vois mal faire un "go to reference Paragraphe", tout en arrivant à suivre le fil de l'histoire.
Certains d'ailleurs critiquent les principes SOLID, car cela amène à découper (trop a priori) au détriment de la lecture (si on compare avec du bon procédural). Je ne suis pas de cet avis, évidemment, il est toujours bon de challenger intention et lisibilité vs découpage.

Dans mon quotidien, je t'avouerai que la plupart des règles sont appliquées, mais pas de manière extrêmement formelle qui ferait casser un build. On applique ces règles avec bon sens pour correspondre au mieux au métier en s'appliquant à obtenir une bonne lisibilité et des intentions claire et honnête.
C'est tout le but de l'exercice ! S’entraîner pour goutter aux bienfaits des principes Clean/SOLID, etc., et pouvoir les appliquer au maximum tous les jours :D

C'est un plaisir d'échanger là-dessus avec toi :)

J'ai l'impression qu'il y a de très bon dev ici =).

Moi qui suis plus débutant que vous, je trouve qu'il manque un "pourquoi", à l'article.

Exemple : "First Class Collections".

Ok, ça à l'air super mais pourquoi ? Ne me jugez pas trop sévèrement si je suis passé à côté.
Sinon l'article est vraiment cool, beaucoup d'exemple et contre-exemple, c'est génial.

Salut Yoan, on est tous ici dans la bienveillance; à partir de moment où tu te pose une question c'est légitime ^^

La plupart du temps le pourquoi c'est pour améliorer la lisibilité du code.

Pour l'exemple de "First Class Collections";
Le but est de révéler l'intention métier lié à la collection.
Dans l'exemple on voit bien que
public function getNumberOfSubscriberWhoOpen()
{
return $this->subscriberCollection
->getSubscriberWhoOpen()
->count();
}
révèle l'intention et permet d'abstraire la plomberie technique.

L'article ne mentionne pas qu'à l'origine il s'agit d'exercices qu'il ne convient pas forcément d'appliquer tout le temps.
Une source primaire : williamdurand.fr/...

Edit : l'article mentionne ces informations.

""
Object Calisthenics are programming exercises, formalized as a set of 9 rules invented by Jeff Bay in his book The ThoughtWorks Anthology. The word Object is related to Object Oriented Programming. The word Calisthenics is derived from greek, and means exercises under the context of gymnastics. By trying to follow these rules as much as possible, you will naturally change how you write code. It doesn’t mean you have to follow all these rules, all the time. Find your balance with these rules, use some of them only if you feel comfortable with them.
""

Pour ce qui est de la règle des collections, je pense que l'intéret est de réduire l'interface uniquement au comportement métier attendu.
On peut par exemple restreindre la collection à l'insertion mais pas à la suppression.

En java, par exemples les collections sont mutables par défaut. Par ex l'interface List expose des méthodes pour ajouter ou modifier des éléments.

La surface d'attaque et les risques de régressions sont augmentées quand les collections ne sont pas wrappées.

Wrapper les collections peut aussi inciter le développeur à nommer le contrat de sa classe (DDD , ubiquitous language).

Ex.

// primitive collection just do collection stuff
shoppingCartItems.add(product);
shoppingCartItems.add(product);

// wrapped collection can be extended with domain semantic and behaviour
shoppingCart.add(product, 2);
shoppingCart.applyDiscountCode("COMPAGNON");

Dans le 2ème exemple la logique d'appliquer un discount n'est qu'à un seul endroit (à l'intérieur de la clases ShoppingCart). Si on manipulait une collection primitive dans tout l'appliacation, cette responsabilité serait déléguée aux clients de la collection qui pourraient faire n'importe quoi avec (leaky abstraction en.wikipedia.org/...