Principes de conception [fermé]

Question

Quels principes suivez-vous généralement lorsque vous concevez une classe?

Answer 1

Principes de la conception de classe orientée objet (les principes "SOLIDES")

• SRP: l'unique responsabilité Principe Une classe devrait en avoir un, et un seul, raison de changer.
• OCP: le principe d'ouverture fermée vous devrait pouvoir prolonger un cours comportement, sans le modifier.
• LSP: la substitution de Liskov Principe Les classes dérivées doivent être substituables à leur base Des classes.
• ISP: la séparation de l'interface Principe Faire un grain fin interfaces spécifiques au client.
• DIP: la dépendance Principe d'inversion Dépend de des abstractions, pas des concrétions.

Source: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

Answer 2

N'oubliez pas la loi de Demeter .

Answer 3

Le S.O.L.I.D. principes .
Ou du moins, j'essaie de ne pas trop m'éloigner d'eux.

Answer 4

Le modèle de conception le plus fondamental devrait être KISS (restez simple, stupide) Cela signifie que parfois, ne pas utiliser les classes pour certains éléments est la bonne solution.

Cette carte et les cartes CRC (Classe, Responsabilité, Collaborateurs) (notez-la dans vos fichiers d’en-tête, et non sur les cartes de cette façon, car elles sont également faciles à comprendre.

Answer 5

Comme mentionné ci-dessus, OCP, LSP, DIP et ISP sont parmi les principes fondamentaux de la conception orientée objet.

Un excellent aperçu de celles-ci par Robert C. Martin (d’Object Mentor) est disponible ici: Principes et schémas OOD

Answer 6

La " L’initialisation est une initialisation " Le paradigme est pratique, en particulier lors de l’écriture en C ++ et de la gestion des ressources du système d’exploitation (descripteurs de fichiers, ports, etc.).

L’un des principaux avantages de cette approche est qu’un objet, une fois créé, est "complet". - il n'y a pas besoin d'initialisation en deux phases ni de possibilité d'objets partiellement initialisés.

Answer 7

faiblement couplé, hautement cohésif.

Composition sur héritage.

Answer 8

La conception par domaine est généralement un bon principe à suivre.

Answer 9

En gros, je m'éloigne de la programmation aux interfaces. J'essaie d'encapsuler ce qui change d'un cas à l'autre pour éviter la duplication de code et l'isoler en morceaux gérables (pour mon cerveau). Plus tard, si j'en ai besoin, je peux alors reformuler le code assez facilement.

Answer 10

Principes solides et modèle de Liskov, ainsi que modèle de responsabilité unique.

Answer 11

Une chose que j'aimerais ajouter à tout cela est la superposition, la définition des calques dans votre application, la responsabilité générale d'un calque, la façon dont deux calques vont interagir. Seules les classes ayant la même responsabilité que celle de la couche doivent être autorisées dans cette couche. Cela résout beaucoup de chaos, garantit que les exceptions sont gérées correctement et que les nouveaux développeurs savent où placer leur code.

Une autre façon de concevoir consiste à configurer votre classe de manière à ce qu'elle soit configurable en créant un mécanisme permettant de brancher la configuration dans votre classe. cette fonctionnalité est dérivée de configurations

Answer 12

J'essaie généralement de faire rentrer la classe dans l'un de ses modèles de conception.