Contrat d'interface, objet de classe?

Question

Le contrat d’interface est-il un objet comme une classe?

Quel est le besoin de différencier des choses identiques comme celle-ci, du code au code d'exécution? J'ai en quelque sorte l'idée de nommer une classe une classe et la classe d'exécution instanciée un objet, mais dans l'ensemble, est-ce la seule raison de ces termes semi-redondants?

Answer 1

Pas vraiment. Il y a quatre termes ici, donc je vais passer en revue chacun d’eux:

Interface

Une interface est une classe abstraite (dans des langages tels que Java, où il n'y a pas d'héritage multiple, il existe parfois d'autres restrictions, telles qu'un type de données séparé) destinée à être utilisée comme base commune pour accéder à un nombre similaire. objets ayant des comportements. Sur le plan conceptuel, l'abstrait n'est pas obligatoire, mais une interface aura généralement au moins une méthode abstraite. Une interface est une méthode permettant à votre programme de communiquer avec un certain nombre de classes similaires, chacune avec une sémantique différente mais ayant le même objectif général.

Contrat

Un contrat est l'accord implicite que vous concluez entre les utilisateurs et les implémenteurs d'une classe ou d'une interface. Par exemple, les conditions préalables et les conditions postérieures (les invariants sont généralement un contrat dans la mise en œuvre de la classe - généralement, des éléments tels que la relation entre les membres internes ne doivent pas être exposés). La spécification d'une valeur de retour ou d'un argument peut également faire partie du contrat. Il représente fondamentalement comment utiliser la fonction / la classe / l'interface, et n'est généralement pas entièrement représentable dans toutes les langues (certaines langues, comme Eiffel, vous permettent de passer des contrats explicites, mais même ceux-ci ne peuvent pas toujours étoffer complètement les exigences ). Lorsque vous implémentez une interface ou dérivez d'une classe, vous devez toujours répondre aux exigences de l'interface ou, lorsque vous surchargez une classe non abstraite, vous comporter de manière suffisamment similaire pour que le visualiseur externe ne remarque pas la différence (il s'agit de Liskov. Principe de substitution: un objet dérivé doit être capable de remplacer la base sans différence de comportement du point de vue extérieur).

Classe

Une classe n’a pas besoin de beaucoup d’essais, car vous les avez clairement utilisées auparavant. Une classe est le type de données et, dans certains langages, un sur-ensemble d’interfaces (qui n’ont pas de définition formelle, comme en C ++), et d’autres est indépendante (comme en Java).

Objet

Un objet est une instance d'un type de classe (ou de tout type non-classe, généralement). La définition exacte d'un objet est très spécifique à un langage, mais la définition générale est ce qui est référé par plusieurs références / pointeurs vers la même chose - par exemple, dans certains langages comme Java, == compare si deux variables sont les même objet, pas nécessairement s’ils sont sémantiquement identiques. Les objets sont indépendants des classes ou des interfaces - ils représentent une seule instance. Une autre façon de penser est que la classe ou l’interface est le moule, et l’objet est l’objet physique qui sort du moule (une analogie plutôt mauvaise, mais c’est le meilleur que je puisse trouver pour le moment).

Answer 2

Non, pas vraiment. Une classe est un modèle que vous définissez. Chaque objet qui instancie cette classe suit le modèle. Ce ne sont pas des termes vraiment redondants, car les deux choses ne sont pas identiques. Vous pouvez considérer une classe comme un type de données défini par l'utilisateur. Les classes et les objets diffèrent les uns des autres exactement de la même manière que le type de données primitif int est différent de la valeur littérale 3.

Une interface définit un ensemble de méthodes que toutes les classes d'implémentation doivent prendre en charge. L'interface elle-même est le contrat que vous définissez pour les classes d'implémentation. Elle indique simplement que toute classe qui implémente l'interface doit avoir le jeu de méthodes publiques de cette interface.

Answer 3

Eh bien, je suppose que ... si une interface spécifie un contrat, une classe spécifie une (ou plusieurs) instance (s) d'un objet particulier.

La terminologie est moins importante que l'application.

Answer 4

En fait, une interface est un contrat, lorsqu'un objet est une instance d'une classe. Ce sont des choses différentes qui n'ont pas trop en commun.

L'interface fournit uniquement une façade pour les objets ou une garantie pour l'appelant que l'objet peut effectuer certaines opérations, même sans en connaître la mise en œuvre.

Par exemple, vous pouvez avoir deux classes implémentant la même interface / contrat, mais faites des choses totalement différentes (même si leur signification peut être la même).

Prenons l’interface IDisposable, par exemple: chaque objet peut libérer les ressources qu’il utilise, mais il peut le faire de différentes façons, il peut choisir de ne rien libérer. C'est le choix de l'objet.

Au moins, ce serait le POV dans .NET

Answer 5

Pour compléter les réponses précédentes, un mot sur les interfaces:

Si la classe est plus qu'un modèle pour un objet (en raison de ses caractéristiques globales indépendantes de toute instance), l'interface peut également être décrite comme un point de vue

Une classe implémentant plusieurs interfaces:

• compléter le contrat à respecter
• permet à l'utilisateur de voir toutes les instances de cette classe du point de vue de celui représenté par l'interface implémentée.

" Point de vue " signifie que vous pouvez utiliser un objet en vous concentrant uniquement sur le contrat défini par cette interface.

C’est dans cet aspect qu’une interface est une "classe abstraite", comme dans une "abstraction". (quelque chose qui reprend certaines des caractéristiques d'une classe, mais laisse certaines autres de côté). Dans le monde Java, une interface laisse beaucoup de place, car elle ne peut être appliquée que pour définir un contrat, par exemple, pas pour des méthodes ou des fonctions statiques.

Answer 6

" Classe " et " Objet " représenter deux choses différentes; ils sont liés, mais ce qu'ils représentent est différent, assez fortement.

La meilleure façon de décrire cela est de regarder Static. Une classe peut avoir des membres statiques, qui sont complètement séparés de toute instance de cette classe. Les objets de cette classe peuvent ou non utiliser ces membres statiques; mais l'instance de l'objet de cette classe est complètement séparée de toute utilisation statique de cette classe (ou devrait l'être, à tout le moins).

Ou pensez au motif singleton. Stocker une instance de l'objet de classe dans un accesseur de classe statique est une pratique courante et montre la différence. Vous vous référez à accesseur statique de classe pour obtenir l'instance d'objet d'une classe singleton; si le membre statique de la classe ne comporte pas d'instance d'objet , la classe crée l'instance de objet .

En d'autres termes; un objet est une instance d'une classe; mais une classe peut être plus qu'un simple modèle à partir duquel des objets sont instanciés. Les membres statiques des classes ont une représentation en mémoire totalement indépendante des instances d'objet de ces classes.