Re: Oh vous savez, moi, l'objet...

À partir du moment où tu as des boîtes noires tu manipules des objets. La POO n'est qu'un formalisme de cette architecture.

Non, ce sont les types de donnés abstraits qui formalisent les boîtes noires. La POO, c'est faire de l'encapsulation avec un enregistrement (record ou struct) de clôtures mutuellement récursives (les méthodes peuvent s'appeler les unes les autres) qui partagent le même environnement (les données d'instance). C'est un cas extrêmement particulier des types de données abstraits, que je n'utilise quasiment jamais parce qu'il ne sépare par les données de leurs méthodes (ce qui est pour moi presque toujours un non sens).

Dans l'exemple à la fin de ce chapitre sur les modules de première classes de Real World Ocaml, ils font de la POO en utilisant les types de données abstraits, bien qu'OCaml soit multi-paradigme et possède un système « objet ». Ce type de données :

module type Query_handler_instance = sig
 module Query_handler : Query_handler
 val this : Query_handler.t
end;;

est équivalent (j'ai envie de dire isomorphe) au type d'un objet au sens de la POO. Mais ici le type de this, à savoir Query_handler.t, est abstrait, c'est-à-dire que les détails d'implémentation son inconnu de l'utilisateur de l'instance. On appelle aussi ce genre de type, type existentiel, parce que la seule chose que l'on puisse dire c'est qu'il existe un certain type t qui est celui de this, mais on ne sait rien sur lui, si ce n'est qu'il possède un ensemble de méthode données par le module Query_handler. Comme on peut le voir, un objet consiste à empaqueter une valeur d'un certain type, avec un ensemble de méthodes le concernant. Mais, il n'est absolument pas nécessaire d'empaqueter ensemble données et méthodes pour faire usage de types de données abstraits. Le type du module Query_handler peut être vue comme un header .h du C qui définit un type sans en exposer les détails d'implémentation. Sa définition est :

module type Query_handler = sig
 (** Configuration for a query handler *)
 type config
 val sexp_of_config : config -> Sexp.t
 val config_of_sexp : Sexp.t -> config
 (** The name of the query-handling service *)
 val name : string
 (** The state of the query handler *)
 type t
 (** Creates a new query handler from a config *)
 val create : config -> t
 (** Evaluate a given query, where both input and output are
 s-expressions *)
 val eval : t -> Sexp.t -> Sexp.t Or_error.t
end

La seule utilité que je vois aux objets, c'est de pouvoir injecter dans un même type (celui de l'objet) des types de données autrement incompatibles (distincts) pour pouvoir les mettre ensemble dans un conteneur homogène (liste, tableaux ...). C'est là seule chose à laquelle ils me servent. Sinon, pour tout ce qui est encapsulation et maintient d'invariant, j'utilise les type de données abtraits sans mélanger données et méthodes dans une même structure.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.