Définissez-vous une interface pour chaque classe publique dans votre modèle de domaine? Avantages et inconvénients?

Question

Implémentez-vous une interface pour chaque classe publique dans votre modèle de domaine? Avantages et inconvénients?

Mise à jour: Si les interfaces de référentiel et les classes de modèle de domaine sont définies dans des assemblages distincts, il n'y aurait pas de dépendance circulaire si nous ne définissons pas d'interfaces pour chaque classe de domaine.

Answer 1

N °

Cons.

1. Code de bruit.
2. Plus à écrire.
3. YAGNI.

Answer 2

Non. Interface uniquement ce dont vous avez besoin à ce moment-là. Si vous essayez de penser trop tôt, votre code deviendra complexe et impossible à maintenir. Dans un petit moment, les programmeurs vont abandonner les interfaces car il est trop difficile de les parcourir pour comprendre ce qui est nécessaire. Tout ce qui est fait pour le faire conduira au désastre.

Answer 3

De mon point de vue, il est trop exigeant. Juste mes 2 cents ...

Answer 4

Non, je ne le fais pas ... Pourquoi le feriez-vous, si ce n'est pas nécessaire pour l'instant?

S'il devait s'avérer que dans l'avenir, il devrait être nécessaire (tous ces 'devraient' indiquer qu'il s'agit d'un YAGNI), vous pouvez effectuer un 'refaire l'interface'.
(IDE modernes rendent très facile à faire).

Answer 5

Je pourrais le faire dans mon prochain projet Asp.Net. Ma raison est que nous, dans le projet actuel, avions besoin d'un endroit pour stocker un état supplémentaire lié à l'interface utilisateur. Si nous avions utilisé des interfaces pour les classes du modèle de domaine, nous pourrions directement dans les sous-classes du code de contrôle de l'utilisateur et la remplacer par notre propre classe qui avait cet état supplémentaire.

Je sais, ça a l'air un peu sale. J'aimerais avoir quelque chose dans le sens du framework Seam de Java avec les mécanismes de conversation.

Answer 6

Vous devez définir des interfaces pour les dépendances entre les couches, pas pour chaque classe. Votre couche Service doit donc dépendre d'une interface de référentiel et votre couche de présentation doit dépendre d'une interface de service. Passé ce délai, il n'y a pas beaucoup de règles strictes, d'autres les utilisent là où c'est logique.

Le bon sens est une bonne partie de tout bon design.

Answer 7

Cela dépend du type de projet. Si vous écrivez une API qui sera fortement réutilisée (comme un wrapper d'API Sharepoint), je serais plus enclin à le faire.

Pour les autres projets qui ne seront pas réutilisés aussi fortement, et par défaut, je ne soulignerais pas l'existence d'une interface pour chaque classe publique. Je préférerais plutôt avoir des couches liées en utilisant des interfaces bien conçues.

Answer 8

Du point de vue de l'immuabilité vous pourriez envisager de mettre des interfaces sur vos objets de domaine:

Dans la plupart des endroits dans votre code, vous voulez que vos objets immuables, de sorte que vous pouvez garantir qu'ils ne seront pas modifiés - Dans ce cas, vous travaillez avec un objet d'accès aux données qui renvoie l'interface, ce qui garantit que votre objet domaine ne peut pas être modifié. Si vous écrivez une page d'administration de quelque sorte où l'utilisateur finira par éditer l'objet de domaine, vous devrez exposer des setters - votre objet d'accès aux données devra renvoyer des instanaces 'MutableDomainObject' (soit une classe ou une sous-interface). Cela dit, je suis d'accord avec la philosophie de YAGNI exprimée ci-dessus - si vous n'avez pas besoin de garantir l'immuabilité pour le moment, cela ne vaut pas la peine d'investir pour le moment. Il ne devrait pas être trop difficile de factoriser les interfaces à une date ultérieure.

Answer 9

Les interfaces peuvent être utilisées pour rendre le code plus expressif en attribuant un nom au rôle joué par une classe dans une situation particulière. Une seule classe peut jouer plus d'un rôle. Par exemple, lorsqu'un homme interagit avec un chat, le chat peut avoir une interface Pet, alors que lorsqu'une souris interagit avec un chat, le chat peut avoir une interface Predator.

Vous pourriez trouver Mock Roles, not Objects une lecture pertinente et intéressante.