Une règle importante de la programmation est de ne pas se répéter (DRY). Il existe divers moyens de se répéter que ce soit en "expliquant du code", représentant les informations plusieurs fois ou encore alors lorsqu'un projet utilise des frameworks ou différents lagunages. 

Il peut y avoir différentes causes à cela : 

• Par inattention,
• Par facilité,
• Par le nombre de développeurs.

Voici quelque point pour éviter de commettre ses répétitions :

• Être attentif à ce que l'on fait,
• Ne pas être trop fainéant, 
• Utiliser des outils pour trouver la duplication de code (comme PMD),
• Communiquer entre développeur.

Avant de chercher à savoir si l'héritage et mieux que la composition ou inversement, observons les divers avantages et inconvénients de ces deux parties respectives. 

Héritage

Avantages

• Facilite la modification et l'extension.

• Facilite l'implémentation grâce au fait que des méthodes sont directement héritées.

Désavantages

• Expose la sous classe à la sur-classe. Cela rompt l'encapsulation ainsi que l'utilisation en "boite noire".
• Rend les sous-classes dépendantes des sur-classes. Si ces dernières changes, la sous-classe devra peut-être modifiée.

Composition

Avantages

• Les objets contenus sont accessiblesuniquement à travers de leurs interfaces.
• Les détails internes ne sont pas connus, "boite noire".
• Réduit les dépendances de mise enœuvre.
• La classe se concentre sur sa propre tâche.
• La composition peut être défini dynamiquement.

Désavantages

• Le système peut avoir tendance à avoir plus d'objets.

Conclusion  

Comme nous l'avons vu, l'héritage n'est pas la solution la plus avantageuse, on l'utilise quand :

• Une sous-classe est "une spécialisation de" et non "un rôle jouer par".
• Une instance de sous-classe n'a jamais besoin de devenir un objet d'une autre classe.
• Une sous-classe étend et ne nullifie pas les overrides ni les responsabilités de sa sur-classe.

Lorsque l'on parle d'optimisation du code, il faut d'abord penser que l'on a une version stable de notre projet.

Il y a peu d'intérêt d'optimiser l'intégralité du projet en même temps que l'on développe ce dernier. Il faut identifier seulement les points essentiels à optimiser comme de grosse boucle qui sont des points couteux de notre programme.

L'optimisation ne doit pas rendre le code illisible car cela rendra l'arrivé de nouveaux développeurs plus difficile ainsi que la maintenance du logiciel plus complexe.

Un dernier point de vigilance avec l'optimisation est le temps. En général trouvé une autre solution optimisée prend toujours un minimum de temps important. C'est pour cela qu'il faut ce limité et ne pas perdre trop de ce précieux temps ! 

Dans cette partie, je ne vous donnerai que des questions aux quels vous devriez essayer de répondre afin de penser à des possibles optimisations ou changement.

• Est-ce que le programme se comporte de la même façon avec un jeu de 50 données ou de 1000 données ?
• Comment le programme réagira s'il y avait une base de données de plusieurs millions d'éléments ? 
• Quelles sont les dépendances entre la taille de certaines structures de données et le temps de calcul ? 
• Le programme consomme-t-il trop de RAM ? de CPU ? 
• Le programme a-t-il un temps de traitement proportionnel à la structure à étudier ? 

Il ne faut en aucun cas programmer par coïcidence. Pourquoi cela ? Car si l'on programme par coïcidence, on ne comprend pas vraiment ce que l'on programme. De plus, on subit notre programme et ce dernier "tombe en marche" et il sera donc difficile de le maintenir car sont fonctionnement nous serait obscure. 

Pourquoi effectuer du refactoring ?

Tout simplement pour aider les autres développeurs qui maintiendront / travailleront sur votre code.
Pour faire cela, il y a de nombreuse étape à effectuer avant de pouvoir dire que le refactoring est terminé : 

• Réparer vos codes.
• Corriger les différents défauts présents dans vos patterns.
• Si un problème ne peut être régler, annoter dans votre code le plus précisément possible pourquoi. Par exemple : "TO DO : make a constructor..." à cause d'un manque de temps, "Not Implemented Yet Because ...".
• Ne surtout pas laisser vos codes se détériorer sinon tout le projet en pâtira.

Quand effectuer du refactoring ? 

Le refactoring, c'est dès le début du projet ! 

Comment EFFECTUER DU REFACTORING ? 

• À l'aide d'outils pour détecter les changements comme des métriques...
• À l'aide d'outils de refactoring.

Organiser son REFACTORING ? 

• Planifiez,
• Prioriser,
• Noter les changements à effectuer,
• Vérifiez les tests avant de refactoriser,
• Progresser étape par étape.