Organizing Data.
Problème : vous avez une association bidirectionnelle entre des classes, mais l'une des classes n'utilise pas les fonctionnalités de l'autre. Solution : supprimez l'association inutilisée.
Problème : vous avez un objet référence trop petit et trop rarement modifié pour justifier la gestion de son cycle de vie. Solution : transformez-le en objet valeur.
Problème : Vous avez deux classes qui ont chacune besoin d'utiliser les fonctionnalités de l'autre, mais l'association entre elles n'est qu'unidirectionnelle. Solution : Ajoutez l'association manquante à la classe qui en a besoin.
Problème : vous avez de nombreuses instances identiques d'une même classe que vous devez remplacer par un seul objet. Solution : convertissez les objets identiques en un unique objet de référence.
Problème : des données métier sont-elles stockées dans des classes responsables de l’interface graphique ? Solution : il est alors judicieux de séparer les données dans des classes distinctes, en assurant la liaison et la synchronisation entre la classe métier et l’interface graphique.
Problème : Une classe contient un champ de type collection ainsi qu'un simple getter et un simple setter pour manipuler la collection. Solution : Rendez la valeur renvoyée par le getter en lecture seule et créez des méthodes pour ajouter/supprimer des éléments de la collection.
Problème : vous avez un champ public. Solution : rendez le champ privé et créez des méthodes d'accès pour celui-ci.
Problème : Vous avez un tableau qui contient différents types de données. Solution : Remplacez le tableau par un objet qui aura des champs distincts pour chaque élément.
Problème : une classe (ou un groupe de classes) contient un champ de données. Ce champ possède son propre comportement et ses propres données associées. Solution : créez une nouvelle classe, placez-y l'ancien champ et son comportement, et stockez l'objet de cette classe dans la classe d'origine.
Problème : votre code utilise un nombre qui a une certaine signification. Solution : remplacez ce nombre par une constante portant un nom lisible qui explique la signification du nombre.
Problème : vous avez des sous-classes qui ne diffèrent que par leurs méthodes (renvoyant des constantes). Solution : remplacez ces méthodes par des champs dans la classe parente et supprimez les sous-classes.
Problème : Une classe possède un champ qui contient un code de type. Les valeurs de ce type ne sont pas utilisées dans des conditions d'opérateur et n'affectent pas le comportement du programme. Solution : Créez une nouvelle classe et utilisez ses objets à la place des valeurs du code de type.
Problème : vous avez un type codé qui influe sur le comportement mais vous ne pouvez pas recourir à des sous-classes pour vous en débarrasser. Solution : remplacez le code de type par un objet d'état. S'il faut remplacer la valeur d'un champ contenant le code de type, un autre objet d'état est « branché » à la place.
Problème : Vous avez un type codé qui affecte directement le comportement du programme (les valeurs de ce champ déclenchent différents codes dans des conditions). Solution : Créez des sous-classes pour chaque valeur du type codé. Puis extrayez les comportements pertinents de la classe d'origine vers ces sous-classes. Remplacez le code de contrôle de flux par du polymorphisme.
Problème : vous accédez directement aux champs privés à l'intérieur d'une classe. Solution : créez un getter et un setter pour le champ, et utilisez-les exclusivement pour accéder au champ.