Bon cas pour les interfaces

interfaces et classes abstraites modélisent différentes choses. Vous dérivez d'une classe lorsque vous avez une relation ISA afin que la classe de base modélise quelque chose de concret. Vous implémentez une interface lorsque votre classe peut effectuer un ensemble de tâches spécifique.

Pensez à quelque chose qui est sérialisable, il n'a pas vraiment de sens (d'un point de vue de conception / modélisation) pour avoir une classe de base appelée sérialisisable car il n'a pas de sens de dire quelque chose d'Isa sérialisable. Avoir quelque chose à mettre en œuvre une interface sérialisable a plus de sens comme disant «c'est quelque chose que la classe peut faire, pas ce que la classe est '

Je ne comprends pas comment ses frais généraux supplémentaires.

interfaces fournissent une flexibilité, un code gérable et une réutilisabilité. Codage à une interface dont vous n'avez pas besoin de vous inquiéter du code de mise en œuvre concret ou de la logique de la certaine classe que vous utilisez. Vous attendez juste un résultat. De nombreuses classes ont une implémentation différente pour la même chose (StreamWriter, StringWriter, XMLWriter). Vous n'avez pas besoin de vous inquiéter de la manière dont ils implémentent l'écriture, il vous suffit de l'appeler.

Le problème avec l'argument de l'héritage est que vous aurez un gigantesque classe de Dieu ou une hiérarchie si profonde, cela fera tourner votre tête. En plus de cela, vous vous retrouverez avec des méthodes sur une classe dont vous n'avez pas besoin ou que vous n'avez aucun sens.

Je vois beaucoup de "non-héritage multiple" et que c'est vrai, cela ne sera probablement pas sous tension de votre équipe, car vous pouvez avoir plusieurs niveaux d'héritage pour obtenir ce qu'ils voudraient.

Une implémentation isisposable vient à l'esprit. Votre équipe mettrait une méthode de disposition sur la classe d'objet et la laisser se propager à travers le système, que cela soit ou non valable pour un objet ou non.

L'argument contre eux est donc: si une classe est correctement configurée (avec son membres publics et privés) alors un L'interface est juste des frais généraux supplémentaires parce que ceux qui utilisent la classe sont restreint aux membres du public. Si tu besoin d'avoir une interface qui est mis en œuvre par plus de 1 classe alors Il suffit de configurer l'héritage / polymorphisme. P>

Considérez le code suivant: p>

interface ICrushable
{
  void Crush();
}

public class Vehicle
{
}

public class Animal
{
}

public class Car : Vehicle, ICrushable
{
  public void Crush()
  {
     Console.WriteLine( "Crrrrrassssh" );
  }
}

public class Gorilla : Animal, ICrushable
{
  public void Crush()
  {
     Console.WriteLine( "Sqqqquuuuish" );
  }
}

Une interface déclare un contrat selon lequel tout objet la mettant en œuvre adhérera à. Cela permet de garantir la qualité de la qualité dans le code plus facile que d'essayer d'appliquer une structure écrite (non codate) ou verbale, le moment où une classe est décorée avec la référence de l'interface Les exigences / contrat sont clairs et le code ne compilera pas avant de mettre en œuvre la mise en œuvre. cette interface complètement et de type-coffre-fort.

Il existe de nombreuses autres raisons pour lesquelles utiliser des interfaces (répertoriées ici) mais ne résonnez probablement pas à la direction, ainsi qu'une bonne déclaration de «qualité» ancienne;)

Eh bien, ma 1ère réaction est que si vous devez expliquer pourquoi vous avez besoin d'interfaces, c'est une bataille en montée de toute façon :)

Cela étant dit, autre que toutes les raisons mentionnées ci-dessus, les interfaces sont la seule façon de programmer des couplies lâches, des architectures N-Ter dans lesquelles vous devez mettre à jour / remplacer des composants à la volée, etc. - dans l'expérience personnelle mais aussi Esoteric Un concept pour la tête de l'équipe d'architecture avec le résultat que nous vivions dans dll enfer - dans le monde .net non moins!

S'il vous plaît, veuillez me pardonner pour le pseudo code à l'avance!

Lisez sur des principes solides. Les principes solides ont quelques raisons pour utiliser des interfaces. Les interfaces vous permettent de découpler vos dépendances sur la mise en œuvre. Vous pouvez également prendre une étape supplémentaire en utilisant un outil tel que StructureMap pour effectuer réellement le couplage de l'accouplement. P>

où vous pourriez être utilisé pour P>

[PluginFamily("Default")]
public interface IAnotherObject
{
    ...
}

[PluginFamily("Default")]
public interface ICallingObject
{
    ...
}

[Pluggable("Default")]
public class AnotherObject : IAnotherObject
{
    private IWidget _widget;
    public AnotherObject(IWidget widget)
    {
        _widget = widget;
    }

    public void SomeMethod()
    {
        //..do something with _widget
    }
}

[Pluggable("Default")]
public class CallingObject : ICallingObject
{
    public void AnotherMethod()
    {
        ObjectFactory.GetInstance<IAnotherObject>().SomeMethod();
    }
}

appologies car cela ne répond pas à votre question concernant un cas pour les interfaces.

Cependant, je suggère d'obtenir la personne en question à lire ..

Tête Premier modèle de conception

- Lee

Les interfaces ne sont pas "requises pour" du tout, c'est une décision de conception. Je pense que vous devez vous convaincre, pourquoi, au cas par cas, il est bénéfique d'utiliser une interface, car il y a une surcharge dans l'ajout d'une interface. D'autre part, pour contrer l'argument contre les interfaces parce que vous pouvez simplement utiliser l'héritage: l'héritage a son tirage, l'un d'entre eux est celui-là - au moins en C # et Java - vous ne pouvez utiliser que l'héritage une fois (héritage unique); Mais le second - et peut-être plus important - est-ce que l'héritage vous oblige à comprendre le fonctionnement de la classe mère non seulement, mais toutes les classes des ancêtres, ce qui rend la prolongation plus difficile mais aussi plus fragile, car un changement de la classe mère ' La mise en œuvre pourrait facilement casser les sous-classes. C'est le creux de la "composition sur l'héritage" argument selon lequel le livre Gof nous a appris.

Vous avez reçu un ensemble de directives que vos patrons ont pensé approprié pour votre lieu de travail et votre domaine problématique. Donc, pour être persuasif sur la modification de ces directives, il ne s'agit pas de prouver que les interfaces sont une bonne chose en général, il s'agit de prouver que vous en avez besoin sur votre lieu de travail.

Comment prouvez-vous que vous avez besoin d'interfaces dans le code que vous écrivez sur votre lieu de travail? En trouvant une place dans votre codeBase actuel (pas dans certains codes du produit de quelqu'un d'autre, et certainement pas dans un exemple de jouet sur le canard mettant en œuvre la méthode Makenoise en Ianimal) où une solution à base d'interface est meilleure qu'une solution basée sur l'interface. Montrez à vos patrons le problème que vous rencontrez et demandez s'il est logique de modifier les directives pour accueillir des situations comme celle-ci. C'est un moment enseignant où tout le monde examine les mêmes faits au lieu de vous frapper sur la tête avec des généralités et des spéculations.

La ligne directrice semble être motivée par une préoccupation quant à la préparation de la généralisation de surenromination et prématurée. Donc, si vous faites une dispute dans le sens de nous devrions avoir une interface ici au cas où nous devrions ... , c'est bien intentionné, mais pour vos patrons, il se détache de la même manière -Les cloches d'alarme qui ont motivé la ligne directrice en premier lieu.

Attendez qu'il y ait un bon cas d'objectif, cela va à la fois pour les techniques de programmation que vous utilisez dans le code de production et que vous commencez les arguments avec vos responsables.