Les principes S.O.L.I.D

Les principes de base de la Programmation Orientée Objet

a marqué ce sujet comme résolu.

Tout le monde se secoue ! :D

J'ai commencé (il y a une heure, suite à une idée de Karnaj) la rédaction d'un tutoriel au doux nom de « Les principes S.O.L.I.D » et j'ai dans l'objectif de proposer en validation un texte aux petits oignons. Je fais donc appel à votre bonté sans limite pour dénicher le moindre pépin, que ce soit à propos du fond ou de la forme. Vous pourrez consulter la bêta à votre guise à l'adresse suivante :

Merci !

+2 -0

Merci pour les liens, ça va me servir ! :)

Au niveau de l'écriture, je suis partant, mais pas pour l'écriture du contenu en tant que tel (pour ça, je peux me débrouiller car ce ne sera pas très très long) ; par contre, si tu maîtrises suffisamment bien un autre langage que le C++, je serai ravi de t'ajouter comme auteur pour que tu puisses écrire des exemples. ;)

EDIT : Sinon, pour la relecture, je ne dis jamais non. :)

+0 -0

Super. Tu as déjà une idée du plan que tu comptes suivre ?

PS : pour la relecture, je suis également volontaire. :)

+1 -0

Pour les exemples pourquoi pas, mais les principes SOLID sont assez agnostiques au langage il me semble.

informaticienzero

Non, ils sont valables pour tout langage orienté objet. Sauf si je n'ai pas compris ce que tu as voulu dire. :)

Super. Tu as déjà une idée du plan que tu comptes suivre ?

Karnaj

C'est à peu près celui qui est en beta : mise au point sur la définition de la POO, puis énoncé et explication des différents principes dans l'ordre (+ loi de Déméter).

+0 -0

Pour les exemples pourquoi pas, mais les principes SOLID sont assez agnostiques au langage il me semble.

informaticienzero

Non, ils sont valables pour tout langage orienté objet. Sauf si je n'ai pas compris ce que tu as voulu dire. :)

mehdidou99

Oui c'est ça que je veux dire. Ça ne dépend pas d'un langage, donc fondamentalement, que ce soit en C#, en Python ou en C++, dans les grandes lignes c'est la même chose.

+0 -0

Ah, d'accord. J'avais donc compris exactement le contraire (en fait, je ne connaissais pas le mot agnostique, j'ai dû mal comprendre la définition que j'ai lue sur internet ^^ ).

A mon avis, c'est tout de même intéressant d'écrire des exemples en plusieurs langages, pour que chacun puisse lire les exemples dans le langage avec lequel il est le plus à l'aise.

+0 -0

Oui c'est ça que je veux dire. Ça ne dépend pas d'un langage, donc fondamentalement, que ce soit en C#, en Python ou en C++, dans les grandes lignes c'est la même chose.

A mon avis, c'est tout de même intéressant d'écrire des exemples en plusieurs langages, pour que chacun puisse lire les exemples dans le langage avec lequel il est le plus à l'aise.

Avoir du code dans un ou deux langages devrait suffire. Le plus important c’est la présentation des concepts. Il y a quelques détails qui changent (classes abstraites, interfaces, etc.), mais c’est le travail des tutoriels sur les langages de les présenter pour que le tout passe bien. Si tu veux quand même mettre des codes dans plusieurs langages tu pourrais peut-être le mettre dans des balises secret.

+0 -0

Un autre lien que je trouve pas mal : http://blog.emmanueldeloget.com/index.php?category/Ood (à lire dans l'ordre chronologique)

Quitte a parler des principes fondamentaux, tu peux étendre à Demeter et l'encapsulation. (En plus, c'est ce que tu fais quand tu parles des accesseurs).

Un gros problème avec les principes est que souvent les gens ne comprennent pas l'intérêt, pourquoi on impose des principes rigides qui "limitent la créativité du développeur" (oui, des guillemets, c'est une citation…).

A mon avis, il faut commencer par contextualiser, en parlant de la qualité logiciel, ses objectifs et en quoi les principes visent à améliorer cela.

Pour chaque principe, il ne faut pas simplement expliqué le principe, mais également convaincre pourquoi c'est important de l'utiliser et comment (ne pas imposer les principes comme un dogme) :

  • les conséquences s'il n'est pas respecté
  • comment reconnaître dans un code qu'un principe n'est pas respecté
  • limites de l'utilisation du principe, quand est il possible de s'en passer

Peut être parler des valeurs/entités (je pense que l'on peut mettre cela dans les principes fondamentaux de la POO).

Et ajouté une partie "Aller plus loin" : architecture logiciel, DP, quoi lire pour approfondir, des mots-clés à rechercher pour aller plus loin.

+3 -0

Salut,

Un autre lien que je trouve pas mal : http://blog.emmanueldeloget.com/index.php?category/Ood (à lire dans l'ordre chronologique)

gbdivers

Merci, j'irai lire.

Quitte a parler des principes fondamentaux, tu peux étendre à Demeter et l'encapsulation. (En plus, c'est ce que tu fais quand tu parles des accesseurs).

gbdivers

énoncé et explication des différents principes dans l'ordre (+ loi de Déméter).

mehdidou99

:)

A mon avis, il faut commencer par contextualiser, en parlant de la qualité logiciel, ses objectifs et en quoi les principes visent à améliorer cela.

gbdivers

Bonne idée.

Pour chaque principe, il ne faut pas simplement expliqué le principe, mais également convaincre pourquoi c'est important de l'utiliser et comment (ne pas imposer les principes comme un dogme) :

gbdivers

C'est prévu, sinon ce cours aurait un intérêt assez limité. :)

  • comment reconnaître dans un code qu'un principe n'est pas respecté

gbdivers

Très bonne idée.

  • limites de l'utilisation du principe, quand est il possible de s'en passer

gbdivers

C'est prévu.

Peut être parler des valeurs/entités (je pense que l'on peut mettre cela dans les principes fondamentaux de la POO).

gbdivers

Bonne idée.

Et ajouté une partie "Aller plus loin" : architecture logiciel, DP, quoi lire pour approfondir, des mots-clés à rechercher pour aller plus loin.

gbdivers

Et enfin, très bonne idée.

Du coup, autant renommer le tutoriel avec un titre qui a à peu près cette tête : "Les principes fondamentaux de l'orienté objet". Qu'en pensez-vous ?

+0 -0

A tout hasard, voici ce que j'utilise pour présenter OO et cie:

+3 -0

Ah et j'allais oublier. J'ai vu passer une note au sujet des sémantiques. Cela n'a pas de rapport direct avec SOLID – hormis que le LSP nous démontre qu'un value object n'est pas héritable, et qu'ISP et DIP ne s'appliquent pas aux sémantique de valeur.

Si cette problématique est très présente en C++ car elle va guider nos choix de copiabilité et d'héritage, en Java et dans les autres langages OO, elle se retrouve, mais sous un angle différent. On retrouve cette discussion au niveau des value objects. Cette fois c'est au niveau de la définition de equals qu'il y a des soucis : on ne peut pas avoir une telle fonction respecter le LSP et la symétrie, et la réflexivité, et la transitivité.

+0 -0

Salut,

La rédaction de ce tutoriel est elle encore vivante ? Si ce n’est pas le cas, étant donné que mon tuto sur la preuve est pour ainsi dire terminé (il va passer sur des relectures plus formelles bientôt), je me lancerai bien là dessus.

Avec quelques questions supplémentaires à ajouter à mon avis :

  • en quoi le pattern "truc" nous permet de mieux respecter "principe"
  • en quoi le pattern "machin" rompt "principe" mais de manière contrôlée

Ciao.

+3 -0

@Ksass’Peuk : Salut, c’est vrai que je ne peux pas avancer du tout cette année, parce que je suis en prépa et que je fais autre chose qu’écrie pendant le relativement faible temps libre que j’ai. Je te passe donc le flambeau de la rédaction avec plaisir, ça me rend un peu triste d’avoir un cours en rédaction qui n’avance pas. :)

@artragis : C’est une bonne idée, à voir avec le nouvel auteur, du coup !

EDIT : @Ksass’Peuk : C’est bon, je t’ai ajouté en auteur, et me suis supprimé. Bonne rédaction !

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte