Consulting, services, computer engineering. Implementation of technology solutions and support for businesses.

User Rating: 5 / 5

Star ActiveStar ActiveStar ActiveStar ActiveStar Active
 

 

D'abord qu'est-ce que le craft? Le terme craft considère que le développement logiciel est davantage artisanal qu'industriel. On va s'attacher à la qualité du code, pour qu'il soit maintenable.

 

Les principes SOLID permettent d'attendre un seuil de qualité et de sécurité satisfaisant.

 

On utilise sa propre technique. Quand on développe une application, le codage est une question de design, on doit faire des compromis. Programmer est un acte d'écriture de communication et d'intention avec d'autres personnes. C'est l'art de raconter une histoire: c'est de la littérature.

 

2 fondateurs de SOLID: Michael Feathers et Robert C. Martin

 

Solid est un ensemble de pratiques pour créer un logiciel plus robuste et plus maintenable.

 

Une question? Posez-la ici

Aide au développement d'applications 

 

Principe SOLID poo : Acronyme SOLID

 

Principe SOLID poo S=Single responsability principle

 

Un artefact ne doit changer que pour une seule raison.

Exemple un militaire entend la sirène sonner.  Soil la base est attaquée, soit il faut partir au front. C'est pareil dans le code, quand on mélange les concepts, ça risque de provoquer des erreurs sur les changements.

 

Exemples en JAVA: on voit une classe qui fait plein de choses, qui crée un utilisateur, qui envoie un mail. Il faudrait que la classe ne fasse qu'une action. Une classe = une action, une responsabilité.

Il y a donc un risque d'incompréhension du code.

 

Principe SOLID poo O=Open closed

 

Ouvert à l'extension, fermé à la modification. Exemple: quand on branche sa Xbox sur la TV, on ne modifie pas la télé, mais on étend usage, c'est l'idée de l'open close: on peut ajouter du code, sans le modifier. 

Quand on a une série de if ou de switch, on est à peu près sûr d'avoir un open closed

 

Principe SOLID poo L=Liskov substitution

 

Principe: toute classe dérivée doit respecter la signature de sa classe mère. Toute interface implémentée doit respecter son contrat.

Exemple: la salade de cigue: quand j'ai une salade à manger avec de la cigue, je dois tester à chaque coup de fourchette s'il y a de la cigue ou pas. Pareil dans le code, on doit utiliser au minimum le null qui ne respecte aucun contrat. Exemple, une classe dérivée carré qui est un rectangle.

La plupart du temps, quand on a un pointeur null, on a ce type de violation.

Instaceof, isnull, nil, none...

 

Une question? Posez-la ici

Aide au développement d'applications 

 

 

 

Principe SOLID poo : I= segregation des interfaces

 

On ne doit pas implementer des choses dont on n'a pas besoin.

Supposons que l'on istalle une cuisine IKEA. IKEA a une notice, API, on doit suivre la notice IKEA, l'interface. Il ne faut pas ajouter 3 vis

Définir l'interface en fonction de celui qui a besoin du service. On ne pourra pas utiliser la notice pour une cuisine LEROY MERLIN.

Une interface fournit des fours

Une interface fournuit des frigos

Une interface fournit des plaques de cuisson...

Ne pas mettre une interface qui fournit une baignoire, car on n'en n'a pas besoin dans la cuisine.

 

 

 

Principe SOLID poo : D= Dependency inversion

Principe de l'inversion de dépendance. Sans ça on n'a pas de testabilité. Dans les années 80, on avait l'invention de la programmation structurée: la main appelait plusieurs fonctions jusqu'au drivers, c'était structuré. Plus on remonte dans les couches, plus on embarque des dépendances. La dépendance du runtime est la même que la dépendance du compiletime. En général on met une interface entre les 2. A l'execution, on peut changer l'implémentation de l'interface.

Par exemple, ça serait comme si dans une usine de construction de voiture on ne pouvait pas changer le type de roues. 

Quand on fait un new explicit. L'usage des singletons etc.

 

 

 

Une question? Posez-la ici

Aide au développement d'applications 

 

La loi de Demeter

Une entité ne doit parler qu'à ses connaissances, pas aux étrangers.

Exemple: quand on passe au supermarché, on achète une baguette de pain. On doit prendre son portefeuille dans la poche de son pantalon pour prendre des euros dans le portefeuille et les donner à la caissière. On ne doit pas donner son pantalon à la caissière qui elle doit attraper le portefuille, l'ouvrir et prendre les euros.

En programmation objet, on ne va pas explorer un objet pour trouver une donnée dont on a besoin, on demande juste la donnée. Quand on commence à à avoir beaucoup de getters et de setters dans un objet, ça commence à être compliqué. Par exemple, quand on fait des streams, de map de map de reduce, on obtient.

 

Ne pas utiliser un enchainement pour trouver la structure d'un objet.  

Principe SOLID poo : maintenant, on code

 

Utilisation d'un IDE en ligne:

https://repl.it/languages/java10

Avec le kata wallet sur le coding dojo:

http://codingdojo.org/kata/Wallet/

On appelle une API exterieure: pour tel type de stock et tel matériau cible, combien ça coute.

Un stock est une action d'un type.  On a un portefeuille avec des euros, des dollars, des bitcoins, on veut savoir combien le portefeuille vaut en euros

Exemple de code en JAVA, pour ceux qui ont pris quelques cours JAVA:

class Main {
public static void main(String[] args) {
System.out.println("Wallet Coding Dojo");
}
}
 
public interface MaConversion{

default void jeconvertis() {

/**
* Fonction de conversion qui sera appelée à chaque conversion.
Intéréssant pour valider le principe SOLID: S=Single responsability principle
*/
}

}

class StockWallet implements MaConversion {

 

@Override
public void jeconvertis() {
MaConversion.super.jeconvertis();
}
}
class Dollars{

int val_dollars;

/**
* @return the val_dollars
*/
public int getVal_dollars() {
 
// webservice
 
return val_dollars;
}

}

class Euro{

int val_euro=1;
// par exemple, on valorise quand on déclare?
// Mauvaise piste, il faut convertir en temps réel...
// Ou pour les tests on peut laisser la valeur à 1 qui sera écrasée...
}

class Petrolleum{

int val_petrolleum=1;

}
class bitcoin{
 
int val_bitcoin=1;

}

Cet article reflète exclusivement l'opinion de ses auteurs et n’engage en aucune façon Consultingit. J'espère que ça vous a plu. Vos commentaires/remarques sont les bienvenus: