Différence entre le modèle et le principe


20

Quelle est la différence entre les modèles de conception orientés objet et les principes? S'agit-il de choses différentes? Autant que je sache, les deux essaient d'atteindre un objectif commun (par exemple, la flexibilité). Alors, puis-je dire qu'un modèle est un principe et vice versa?

Principe de conception = SOLIDE (c.-à-d. Principe d'inversion de dépendance)

Modèle de conception = Gof (c.-à-d. Modèle d'usine abstrait)

Réponses:


24

Non, ce n'est pas pareil.

Les modèles sont des solutions courantes aux problèmes de programmation orientée objet . (Je ne connais aucun livre similaire pour une programmation fonctionnelle ou déclarative.) L'idée a été cristallisée dans le célèbre livre "Design Patterns" du Gang of Four en 1995.

Comme le souligne André, les schémas sont courants dans tous les paradigmes. Je réitère ma déclaration précédente: je ne connais aucun livre similaire pour la programmation fonctionnelle ou déclarative, mais Andre a remédié à mon ignorance avec le lien qu'il a fourni ci-dessous. (Merci, André.)

Les principes concernent moins des langues ou des paradigmes particuliers, plus généraux. "Don't Repeat Yourself" - principe DRY - est vrai pour toute la programmation.


4
Les modèles existent dans chaque paradigme. Jeremy Gibbons écrit un livre intitulé Patterns in Functional Programming (et blogue à ce sujet ici ). Les motifs sont exactement ce que le nom dit - des conceptions récurrentes, qui résolvent des problèmes similaires. Ils sont partout », même si vous ne les reconnaissez pas toujours.
André Paramés

@ AndréParamés Un survol rapide me porte à croire que Jeremy Gibbons parle d' idiomes linguistiques , pas de modèles de conception.
Izkata


19

Ces concepts ne sont pas les mêmes:

* Principe de conception: * Les principes de conception de logiciels représentent un ensemble de directives qui nous aident à éviter d'avoir une mauvaise conception. comme: Open Close Principle

* Design Pattern: * un Design Pattern est une solution générale réutilisable à un problème courant dans un contexte donné dans la conception de logiciels. Comme: Singleton


7

Les modèles sont des principes, ce que les implémentations sont des modèles.

Un principe serait "l'indirection", qui pourrait être accompli par un modèle "d'usine", qui est implémenté en tant que classe avec des méthodes d'usine à la fin.


3

Eh bien, les principes sont des règles tandis que les modèles sont leurs exemples concrets.


1
Pouvez-vous donner quelques exemples?

Veuillez nous indiquer le principe qui nécessite une usine, une chaîne de responsabilité ou une masselotte.
duffymo

2
@duffymo Well Factory, par exemple, suit le principe d'inversion de dépendance (pas l'injection); le client et l'instance dépendent de l'abstraction - l'interface. La chaîne de responsabilité est basée sur les principes de couplage et de séparation lâches des contrôleurs. Flyweight, je crois, n'a que des gains de performance.
m3th0dman

3

Les modèles sont plus des choses de haut niveau que des principes. Les modèles résolvent des problèmes spécifiques. Les principes pourraient être appliqués n'importe où, quel que soit le contexte. En fait, des modèles basés sur des principes (SRP, DRY, etc.)

EG Regardons le modèle de stratégie. Il définit une famille d'algorithmes, encapsule chacun d'eux et les rend interchangeables. Donc, vous avez ici un concept d'algorithme de haut niveau. Avec le modèle d'État, vous avez un concept d'État de haut niveau. Avec des principes, vous n'avez pas de concepts de haut niveau. Les principes sont des éléments constitutifs qui sont utilisés par les patters pour atteindre l'objectif. Lorsque vous implémentez un modèle de stratégie, vous utilisez SOLID:

  • SRP - vous définissez le code, responsable de l'algorithme et l'extrayez d'un autre code.
  • OCP - vous définissez l'abstraction, qui représente tous les différents algorithmes et l'utilisez
  • LSP - vous n'utilisez pas de classes d'algorithmes concrètes dans le code client, seulement l'abstraction

5
En fait, les modèles sont d'un niveau inférieur aux principes. C'est-à-dire qu'un schéma est plus proche de la mise en œuvre réelle qu'un principe dans ce contexte. En d'autres termes, les principes sont plus abstraits que les modèles dont les principes signifient des directives générales de conception et des modèles représentant des solutions adaptées à une classe particulière de problèmes.

@Jarkko voir mon exemple. Quand j'ai parlé de niveau, je voulais dire que les modèles sont basés sur des principes, et non vice versa. La brique n'est pas une chose de plus haut niveau que la construction.

4
Je peux voir ce que vous vouliez dire par là et comprendre votre réflexion à ce sujet. Elle est cependant contraire à la signification commune des concepts "haut niveau" et "bas niveau" dans le contexte des logiciels. (Pour une raison quelconque, je ne peux pas @ -tag vous.)

1
"Les modèles sont plus des choses de haut niveau que des principes". Je prie de différer ==> Un modèle est proche de la réalisation (c'est-à-dire de bas niveau), tandis qu'un principe est une règle de haut niveau.
Raúl

2

Les modèles ont été initialement documentés pour l'architecture. En architecture, s'appliquent à des choses allant du placement de la porte dans une pièce à l'aménagement d'un village.

Le Gang of Four a appliqué l'idée à la programmation orientée objet. Il peut y avoir plus d'un modèle qui peut être utilisé pour résoudre un problème, mais chaque modèle aura une implémentation spécifique. Des modèles existent dans d'autres approches de programmation, mais je ne connais aucun livre applicable. Comme d'autres l'ont mentionné, les modèles couvrent des implémentations spécifiques. L'utilisation d'un modèle lorsqu'il ne s'applique pas est souvent considérée comme un anti-modèle.

Les principes ne couvrent pas la mise en œuvre, bien qu'il puisse exister des approches de mise en œuvre standard. Les principes visent davantage à couvrir des questions générales plutôt que des problèmes spécifiques. Pour Inversion of Control, je connais au moins trois approches d'implémentation. Pour DRY (Don't Repeat Yourself), je ne connais pas d'approche d'implémentation spécifique au singe, bien que j'en utilise plusieurs.

Considérer

  • Il vous a été demandé d'utiliser un modèle comme Abstract Factory Pattern comme seule approche pour développer un programme. Serait-ce approprié? Non, alors c'est plus probablement un Pattern.
  • Vous avez été invité à appliquer SEC sur tous les composants? Serait-ce approprié? Oui, alors il est plus probable que ce soit un principe.

1

Principe de conception OO—

Le principe OO est un ensemble de directives qui garantit le concept OOP. Basé sur le concept OOP, cela définit des façons de concevoir une meilleure façon, une meilleure conception. Le principe de base de la conception OO est SOLIDE.

Un modèle de conception fournit une solution générale à un problème de conception. Veuillez noter que le «motif de conception» peut également être appliqué à un mot orienté objet à midi. Ainsi, les modèles de conception A OO (OODP) sont ceux qui fournissent une solution générale au principe OO basé sur la conception orientée objet. Les modèles de conception sont découverts, pas inventés. Il existe plusieurs façons de définir les OODP et la plus connue est la BSC [Behavioral Structural Creational].

Voici le lien pour une explication détaillée. http://techythought.wordpress.com/2013/01/21/design-principle-vs-ds-design-pattern-describing-oop-elements/

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.