Organiser son code

Petit exercice

  1. Implementer un objet Afficheur :
  2. avec une methode afficher(String message) qui System.out.printLn(message)
  3. Ajouter un verification si la string contient un “a” on affiche pas le message
  4. Dans une methode main : Avoir 2 instanc d'afficheur un qui affiche le message en Minuscule et l’autre en Majuscule
  5. Ajouter un check pour l’afficheur en majuscule, il faut que la string fasse 5 charactere
  6. Faire une troisieme version qui doit afficher normalement et uniquement verifier si la chaine de caractere a une taille de 5

Principe Solide

S Single responsibility principle
O Open/closed
L Liskov substitution principle
I Interface segregation principle
D Dependency inversion principle

Eviter les objets fourre tout/trop gros (S)

  • Valable sur les services et les entités (Qui sont souvent la racine du probleme)
  • Decouper les objets en "groupe logique" 
    								
									public class Client{
										private String raisonSociale;
										private String ville;
										private String rue;
										private String codePostal;
									}
  • Decouper les objets en "groupe logique" 
    								
									public class Client{
										private String raisonSociale;
										private Adresse adresse;
									}
									public class Adresse{
										private String ville;
										private String rue;
										private String codePostal;
									}
  • Decouper les objets en "groupe logique" 
    								
									public class Client{
										private String raisonSociale;
										private Adresse adresse;
										private Adresse adresseFacturation;
									}

									public class Adresse{
										private String ville;
										private String rue;
										private String codePostal;
									}
  • Decouper les objets en "groupe logique" 
    								
									public class Utilisateur{
										private String nom;
										private String prenom;
										private String mail;
										private String password;
									}
									public class Docteur{
										private Utilisateur utilisateur;
										private String numeroPraticien;
									}
									public class Patient {
										private Utilisateur utilisateur;
										private Docteur docteur;
									}

Composition over abstraction

  • L'abstraction n'est pas la solution pour factoriser du code
  • 90% du temps l'abstraction est mal utilisé (Source moi )

    Mauvais exemple 

    									
										public class AbstractBidule{
											abstract void doSomething()
											public void doOther(){
												...
												(doSomething is never called)
												...
											}
										}
										public class BiduleTruc extends AbstractBidule{
											@Override
											void doSomething(){
												this.doOther()
											}
										}

    Bonne exemple 

    									
										public class AbstractBidule{
											abstract void doSomething()
											abstract boolean doThird()
											public void doOther(){
												if(this.doThird()){
													this.doSomething()
												}
											}
										}
										public class BiduleTruc extends AbstractBidule{
											@Override
											void doSomething(){
												....
											}
											@Override
											boolean doThird(){
												....
												return result;
											}
										}

Bonne pratique : Designer son api rest

Ne pas retourner les entité dans les controllers

  • Eviter beaucoup de probleme (Serialisation cyclique, cacher des champs (Password...))
  • Maitriser le schema
  • Versionner l'api
  • Utiliser un DTO

Découper les ressources

Objet exemple :

								
										public class Animal{
											private Long id;
											private String nom;
											private List<Animal> enfants;
											private List<Repas> repas;
											private Espece espece;
										}

Mauvaise pratique

Get /animals/12 
						
							{
								"id": "12",
								"nom": "Paul",
								"enfants" :[
								  {
									"id": "13", 
									"nom": "Paul2"
								  }
								],
								"repas": [],
								"espece": {
									"nom": "pingouin"
								}
							}

Bonne pratique

Get /animals/12

								
									{
										"id": 12;
										"nom": "Paul"
										"espece": {
											"nom": "pingouin"
										}
									}

Get /animals?parent=12

								
									[
										{
											"id": 13;
											"nom": "Paul2"                
										}
									]

Get /repas?animal=12

								
									[
										{
											"id": 13;
											"nom": "Paul2"
										}
									]

Utilisation des verbes

  • Decrire une action : /fusees/12/launch
  • Eviter les :
    • init : Le post suffit
    • search : Le get sufit
    • delete : le verbe http existe

Bonne pratique : organiser son code

Ranger les packages : 1 Niveaux

						app/
						|- config/
						|- controller/
						|- repository/
						|- service/
						|

Ranger les packages : Domaine

						app/
						|- compta/
						| |- config/
						| |- controller/
						| |- repository/
						| |- service/
						|
						|- facture/
						| |- config/
						| |- controller/
						| |- repository/
						| |- service/

Ranger les packages : Domaine

  • Regrouper les element par domaine fonctionnel
  • Facilite l'exploration du projet

Ranger les packages : En domain + identifier les entre sortie

						app/
						|- compta/
						| |- config/
						| |- in/
						| |	|- controller/
						| | |- amqp/
						| |- out/ 
						| | |- repository/
						| |- service/
						|
						|- facture/
						| |- config/
						| |- in/
						| | |- controller/
						| |- out/
						| | |- repository/
						| | |- compta/
						| |- service/

Ranger les packages : En domain + identifier les entre sortie

  • Identifier les dependances
  • Faciliter les études d'impact