Rubrique « Info »

Pour résumer :

• Un type représente une "caractéristique" (issue d'un travail d'abstraction qui est introduit dans l'article sur les types)

• Une classe est une collection d'objets ayant en commun :
  - des responsabilités (en anglais "features" ou "responsability", à savoir :
          * les attributs qui représentent la "responsabilité" de savoir quelque chose 
          * les méthodes qui représente la "responsabilité" de faire quelque chose).
      (on verra plus bas que attributs et méthodes sont  des "types dérivés", donc une classe
       peut être vue comme une collection d'objet partageant des caractéristiques communes)
  - des invariants (qui définissent :
          * comment les éléments sont reliés entre eux, par exemple au travers de règles de visibilité - public, protected, private -, 
          * les conditions de viabilité des objets)
  Une classe implémente un type (cf. type d'objet pour bien comprendre). 
  (dixit [OOM-PP])

• Un objet est un concept autonome et actif identifié comme un élément physique "réel" ou un concept abstrait.
  Un objet instancie une classe, mais peut lui-même être une classe (auquel cas sa classe sera une "méta-classe").
  Or une classe est un "type dérivé", donc un objet peut être un "type dérivé"...
  Dans tous les cas, un objet est fondamentalement une notion dynamique : 
  Un objet est un acteur d'un scénario d'échange de messages : il envoie et reçoit des messages et change son état local.
  Un objet possède donc : ([vassar])
  - une structure ;
  - un état ;
  - un ensemble d'opérations lui permettant de générer des messages ;
  - un identifiant lui permettant de distinguer d'autres objets de même classe et de même état. (Typiquement, un objet se distingue d'un autre par son adresse mémoire, par exemple).
  
  Pour bien comprendre la différence entre objet (point de vue dynamique) et classe (point de vue statique), on peut préciser les notions de :  ([schupp])
  

• message (dynamique) : requête envoyée d'un objet à un autre via une opération. Chaque message à un destinataire identifié. L'expéditeur attend du destinataire qu'il traite le sa requête. La façon dont le message est interprété dépend des méthodes supportées par le destinataire. L'expéditeur ne connaît pas les actions précises faites par le destinataire, du fait du masquage d'information. La requête sera exécutée par une méthode publique qui pourra utiliser en interne une ou plusieurs méthodes privées...

• méthode (statique) : spécification des opérations faites par un objet lors de la réception d'un message. Il doit y avoir une correspondance 1-1 entre un message donné et une méthode exécutée pour un objet d'une classe donnée.
  Mais des objets de différentes classes peuvent exécuter des méthodes différentes pour un même message : c'est le cas dans le polymorphisme, où un même message arrive à des méthodes de signature identique mais au contenu très différent.

• opération (dynamique) : implémentation d'une méthode, afin de pouvoir générer un message. La boucle est bouclée ;)

Les Types : leurs principales catégories sont énumérées ci-dessous mais sont détaillées dans le questionnaire Langage de Programmation, plus précisément dans les réponses aux questions sur les types.

On distingue 2 sortes de "types" (ou caractéristique) (d'après [AnnotedC++]):

• les types de base (anglais : "fundamental type") : Cf. types de base.

• les types dérivés, qui se construisent d'une façon ou d'une autre à partir des type de base. cf. types dérivés.

Pour être plus précis, [schupp] rappelle dans son cours "Data Type" les 5 catégories de type : Cf. 5 types.

• Primitive types Cf. types simples.
  
  Les catégories qui suivent sont des types dérivés.

• User-defined ordinal types Cf. types ordinaux.

• Aggregates Cf. types agrégats.

• Abstract data types Cf. types abstraits.

• Parameterized Types (Generics) Cf. types génériques.
  

Qu'est-ce que le type d'un objet ?

    Souvenons-nous qu'un objet est aussi bien instance que classe.... que type ! Alors parler du "type d'un objet", cela peut donner mal à la tête. Cela fait avant tout référence à sa structure (évoquée ci-dessus lors de la définition d'un objet).
    On peut parler de l'objet "Voiture" (instance de la classe "Classe" ou, en UML1.4, de la classe "Classifier"), comme de l'objet "BMW" (instance de la classe "Voiture").
    Dans tous les cas, le type d'un objet représente la spécification de sa classe, du point de vue de l'intention de la classe (quelles sont les caractéristiques que la classe est censée représenter ?), et non de l'extension de la classe (quelle est la liste exhaustive, "l'implémentation" précise des caractéristiques de cette classe ?)
    Ainsi, le type de l'objet "Voiture" est un type dérivé composé de responsabilités (attributs et  méthodes) qui représentent ce que la classe est censée savoir ou faire.
    Par exemple, le type de l'objet "Voiture" est censé avoir une vitesse et pouvoir rouler.
    La classe "Voiture" qui implémente le type d'objet "Voiture" peut le faire de mille façons différentes, rien que pour représenter la vitesse : via un attribut vitesse ou une méthode getVitesse() qui calcule la vitesse en fonction de la vitesse de rotation des roues et de leur diamètre! Le fait de "savoir rouler" peut se traduire, s'implémenter par des méthodes aussi diverses que "démarrer", "embrayer", "freiner", ... toutes contribuant à implémenter les responsabilités de savoir-faire définies par le type de l'objet "Voiture". 
   Le "type d'un objet" est donc plus un concept qu'une "réalité" manipulée quotidiennement par les programmateur en langage objet. Ceux-ci connaissent se servent d'abord du type dérivé pour définir le "type d'une classe" (cf. paragraphe suivant)
   Donc, le plus souvent, parler du type de l'objet est un abus de langage pour désigner le type de la classe qui instancie l'objet !!!

Qu'est-ce que le type d'une classe ?
    C'est plus simple que le "concept" de type d'objet : c'est l'interface publique de la classe (composée de méthodes, mais aussi d'attributs, bref, de "caractéristiques" qui  résulte d'un travail d'abstraction). De toute classe on peut en déduire un type, et cela joue un rôle dans l'héritage de Type, une des 2 sortes d'héritages utilisées en langage objet.

Différence entre type et interface ?
    En relisant l'article sur le polymorphisme, on a vu que, par binding de valeur, on accède au polymorphisme dynamique d'inclusion. 
   Le type d'un objet (abus de langage pour désigner le type de la classe instanciant l'objet) est la plus grande interface possible, celle présentant à l'utilisateur toutes les fonctions de la classe instanciant l'objet... pour peu que l'on mette cet objet dans une variable de même type (le fameux binding de valeur évoqué ci-avant).
Ainsi :
Base {
  void m();
}
Derived : public Base {
  void m2();
}
Base    aBase    = new Derived();
Derived aDerived = new Derived();
    Dans les 2 cas, le type de l'objet "new Derived()" est Derived... mais le "type de la variable" aBase agit comme une interface qui filtre les fonctionnalités de "new Derived" pour ne laisser que celles de la classe Base.
    Lorsque ce filtre offre toute les fonctionnalités de l'objet (ce qui est le cas de la variable aDerived), type de l'objet et interface sont confondus.
    Donc, un objet n'a qu'un type, mais, au travers des variables auxquelles l'objet sera assigné, plusieurs interfaces possibles, que sont ses types parents.

Et l'interface en java, alors ?
    "interface", en java, est un type sans aucune implémentation ni attribut. Du coup, lors d'héritage multiple, on évite tout problème d'implémentation multiple...
    Et alors ?
2 classes liées par des types commun vont partager une implémentation commune.
Mais 2 classes liées par une interface java commune pourront très bien n'avoir aucune implémentation commune ! Le polymorphisme dynamique d'inclusion qui consiste à appeler la bonne implémentation pour une méthode donnée fonctionnera alors que ces méthodes ne surchargent aucune implémentation parente.