Comme nous l'avons vu dans le résumé, le principe de l'Expert en Information consiste à ce qu'une classe et une seul responsabilité.
En ce qui concerne le principe créateur il permet de définir qu'elle classe doit créer des instances d'une autre classe.

Je vais vous donnez les 4 règles pour savoir si une classe B peut créer une instance d'une classe A :

• La classe B contient des objets de la classe A.
• La classe B enregistre des objets de la classe A.
• La classe B utilise étroitement des objets de la classe A.
• La classe B contient les données d'initialisation qui doivent être utilisé pour la créationdes objets de la classe A.

Nous allons donc voir cela avec la modélisation d'un système de forum. Nous allons chercherons à savoir qui va devoir implémeter la méthode posterMessage(String str) entre notre forum, notre canal ainsi que notre message.
Pour vous situer un peu plus, nous avons un forum avec différents canaux de différents type qui contient lui même des mesages.

Dans notre cas, comme notre canal est lié au forum et qu'un canal contient des messages on peut facilement savoir que l'expert pour cette méthode est le canal. De plus, c'est bien le canal qui va créer notre message car le canal contient des messages dans une liste de ces attributs.

Voici la conception général de tout notre système.

Comme nous l'avons vu dans le résumé, le principe le couplage est la notion qui évalue comment sont lié deux éléments, un couplage faible correspond donc à deux classes peu liées. Ce faible couplage nous permet d'avoir une meilleure réutilisation, un changement dans une classe liées aux autres n'impacte pas ces dernières ainsi qu’une meilleure compréhension du code. 

Étudions le couplage du code ci-dessous provenant de notre controleur.

Dans cette méthode, on observe que le controlleur est liée au Forum (ligne 147), ainsi qu'au Canal (ligne 152), au CanalType (ligne 151) ainsi qu'à l'InterfaceUtilisateur (ligne 160/164 et 168). Notre controlleur est donc liée à 4 classes. On peut dire qu'il est moyennement lié et donc qu'il a un couplage moyen.

Attention, ce n'est pas parcequ'une classe est fortement liée que le code n'est pas forcément propre. C'est le cas pour java.util par exemple. Cela reste donc en discussion permanente pour savoir si cela le couplage est important.

Comme nous l'avons vu dans le résumé, le principe du controleur est de faire le lien entre l'ihm est le reste de notre code, la partie métier. Il joue donc un rôle important. Il à lui aussi sa représentation particulière dans un diagramme de séquence (voir ci-contre). Je ne dirais pas grand chose de plus car le controleur reste assez simple. 

Comme nous l'avons vu dans le résumé, le principe de forte cohésion est le couplage avec les responsabilités d'un élément.

Pourquoi vouloir que nos classes aient une forte cohésion ? C'est pour maintenir une complexité gérable, un maintien plus simple. Pour savoir si une de nos classes à une forte cohésion, un moyen est de réussir à décrire la classe en une seule phrase. 

Nous allons donc voir un exemple avec une faible cohésion puis sa correction en forte cohésion. 

Dans ce diagramme de séquence, pour poster un message, on observe que le forum effectue différente méthode comme créer le message, changer le type du canal ou encore affecter au canal. Hors dans ce cas, comme nous l'avons vu précédemment, en analysant le couplage on voit  que la classe forum à un fort couplage. Et en ce qui concerne les responsabilités, notre classe, forum a de multiple responsabilités comme celle de créer un message, modifier un canal. 

Maintenant, essayons de corriger cela. Pour avoir un couplage plus faible, nous devons essayer d'analyser si des liens sont inutile ou mal placé pour les corriger (dans ce cas nous dirons que tout est nécessaire est placé correctement). Le deuxième point à analyser est l'affectation des responsabilité. Je vous laisse réfléchir à ce point puis vous pourrez regarder la solution ci-dessous.

Comme nous l'avons vu dans le résumé, le principe du polymorphisme permet à un objet d'avoir "différent type".

Le polymorphisme est une notion importante qui nous permet d'ajouter facilement de nouvelle implémentation.

Pour comprendre cela, utilisons l'exemple ci-dessous.

Pour vous donner un contexte, cette partie de diagramme représente l'état d'un joueur. Le personnage peut-être en vie, Living mais aussi faible en vie, Low ou alors il peut être mort, Dead. Le personnage à toujours un état, State.

On observe sur ce diagramme que nous avons 3 classes Dead, Living et Low héritant d'une classe abstraite State. Comme ces objets héritent de State,  il doivent tous implémenter la méthode getProtection() car State la déclare. Mais en héritant de State, tous ces objets peuvent être stocké dans un attribut State. On pourra donc avoir un code comme cela par exemple (voir ci-dessus). Nous pourrions aussi ajouter de nouvelle classe étendant State facilement comme FullLife qui nous permetrait d'avoir un nouveau comportement de getProtection() facilement.

Nous avons donc différents état (State) concret qui peuvent facilement utiliser le polymorphisme pour être assigner à un personnage.

Comme nous l'avons vu dans le résumé, le principe de la fabrication pure consiste à améliorer la réutilisabilité. Ce principe est utilisé lorsqu'il n'y a pas de concept réel pouvant être utilisé pour avoir un faible couplage et une forte cohésion. 

Pour réussir à obtenir ce faible couplage et cette forte cohésion, il est possible de de créer de toute pièce certain concept de toute pièce. J'entends par la que l'on peut créer un concept / classe qui n'existe pas dans le monde réel mais que l'on peut retrouver. Pour illustrer cela, voici un exemple. 

La fabrication de de la main a permis d'augmenter la cohésion entre nos différents éléments ainsi que de baisser le couplage.