Est-il préférable de passer une * interface * ou un * objet * en tant que paramètre d'une fonction?

Question

J'essaie de convaincre un collègue qu'une fonction doit prendre une interface en tant que paramètre et non l'objet lui-même. Je pense que les petits objets peuvent facilement passer, mais pour les plus gros, je leur donnerais une interface et ne ferais que passer le i / f, pas le tout.

Notez qu'il n'y aura jamais qu'une seule de ces grandes classes - le i / f ne sera jamais utilisé pour un objet différent. C'est simplement pour cacher l'implémentation d'un objet.

Accepteriez-vous que la séparation d'une classe nombreuse dans une interface est une bonne pratique?
Y a-t-il des inconvénients à le faire?

Exemple:

public interface class IVeryLargeClass
{
    void DoSomething();
    ...
};

public ref class VeryLargeClass : public IVeryLargeClass
{
public:
    virtual void DoSomething() { ... }
    ...
};

public ref class AnotherClass
{
public:
    AnotherClass(VeryLargeClass^ vlc)  { vlc->DoSomething(); }
 // OR
    AnotherClass(IVeryLargeClass^ vlc) { vlc->DoSomething(); }
};

Answer 1

L'un des premiers principes que vous apprenez dans le développement OO:

  

Programmez une interface, pas une   mise en œuvre.

Vous indiquez qu'il "n'y aura jamais qu'une seule de ces grandes classes - le i / f ne sera jamais utilisé pour un objet différent". C’est peut-être vrai dans votre cas, mais j’aurais bien aimé en avoir un sou pour chaque fois qu’une telle affirmation se révélait fausse.

Outre la possibilité d'implémentations multiples de votre interface, vous devez également déterminer si votre objet concret exporte (ou pourrait exporter) des méthodes supplémentaires qui ne partagent pas une affinité logique avec les opérations déclarées dans l'interface. Dans ce cas, vous pouvez simplement déclarer les opérations supplémentaires dans une ou plusieurs interfaces supplémentaires. Un client n'a donc besoin que de coupler l'interface qui exporte les opérations qui l'intéressent.

En termes simples, les interfaces permettent de gérer le couplage entre clients et fournisseurs.

Answer 2

Le principe d'inversion de dépendance peut être résumé comme suit: Il est préférable de: dépend des abstractions que des concrétions.

Il est presque toujours préférable de passer d'une interface à une classe concrète.

Cela dit, une forte cohésion vis-à-vis des types internes est acceptable dans un module particulier, mais c'est très subjectif de savoir quand et comment passer des objets concrets.

Answer 3

Je préférerais éviter de créer et d’interfacer pour créer une interface. Si vous pouvez utiliser cette interface à plusieurs endroits, vous avez un gagnant - ou s’il s’agit d’une fonction et d’une classe publiques et que vous souhaitez simplifier.

Answer 4

Si vous réussissez une implémentation, vous perdez un des avantages de l'utilisation d'interfaces, ce qui signifie que vous séparez la logique de l'implémentation réelle.

  

L'interface d'un module logiciel A   est délibérément maintenu séparé de la   la mise en œuvre de ce module. le   ce dernier contient le code réel du   procédures et méthodes décrites dans   l'interface, ainsi que d'autres   "privé" variables, procédures, etc.   Tout autre module logiciel B (qui peut   être considéré comme un client pour A) que   interagit avec A est obligé de le faire   seulement par l'interface. Un   avantage pratique de cette   arrangement est que remplacer le   mise en oeuvre de A par un autre   qui répond aux mêmes spécifications de   l'interface ne doit pas amener B à   échouer - tant que son utilisation de A est conforme   avec les spécifications de la   interface (voir aussi Liskov   principe de substitution).

http://en.wikipedia.org/wiki/Interface_(computer_science)

Answer 5

L’autre problème concerne votre très grande classe elle-même. Cela n’entre peut-être pas dans le cadre de ce que vous faites, mais une très grande classe implique qu’elle en fasse trop au début. Pouvez-vous le reformuler dans une classe plus petite, où les informations requises dans la fonction que vous appelez sont encapsulées dans sa propre classe plus petite? Si vous créez une interface contre cette classe, vous la trouverez peut-être beaucoup plus réutilisable que contre la très grande classe que vous avez actuellement.