Discussion :

[oodini]

Bonjour,

Je travaille avec une API qui a la particularité de ne pas avoir de classes "mixtes".

C'està-dire que ses classes sont soit exclusivement composées de données, soit exclusivement composées de fonctions.

Pour agir sur les données membres d'un objet, il faut associer l'objet "données" à un objet "fonctions" correspondant.

L'objet fonction est instancié en passant au constructeur l'instance de l'objet données. Tout appel aux fonctions de cet objet fonctions agira sur l'ojet données qui lui a été donné à la construction (ou éventuellement resetté plus tard).

Ce style de conception a-t-il un nom ? Comporte-t-il certaines règles ?

Par exemple, j'ai l'impression qu'il m'est impossible de passer une instance de classe de fonction comme paramètre d'une fonction quelconque.
De plus, l'opérateur & des classes de fonction est surchargé et privé, ce qui rend impossible toute récupération de l'adresse.

Merci

[ZaaN]

Par exemple, j'ai l'impression qu'il m'est impossible de passer une instance de classe de fonction comme paramètre d'une fonction quelconque.

a quoi bon instancier les classes contenant les fonctions uniquement ? (d'ailleurs ca me semble logique que ca ne marche pas)

Du moment que tu arrive a appeler les fonction depuis l'instance des données, ca doit permettre de tout faire !?

[koala01]

Salut,

Il n'y a que deux cas dans lesquels il soit cohérent de ne fournir que des fonctions dans une classe:

• Si la classe va servir d'interface à un arbre d'héritage (les fonctions sont alors virtuelles pures)
• Pour regrouper un ensemble de fonctions statiques, qui ne nécessitent aucune données externe

Dans le premier cas, cela sous-entend que les fonctions déclarées comme virtuelles pure devront toutes être implémentées dans les classes héritière, sous peine d'obtenir une classe non instanciable car "abstraite", et, dans le second cas, on préférera souvent utiliser plutôt un espace de nommage

Le principal problème à la conception sous forme de "données à gauche, méthodes à droite" réside en deux points:

• Tu pars quasi systématiquement sur un héritage multiple, (ben ouaip, il faut hériter de la classe "data" et de la classe "methodes"... Même si on peut envisager un héritage de la classe "methodes" et une agrégation avec la classe "data"), et, tant qu'à faire, c'est quelque chose qu'on préfère éviter
• Tu te retrouve obligé de déclarer des amitiés à n'en plus finir: tout classe "methode" devra systématiquement être déclarée comme amie avec les classes "data" qu'elle est sensée gérer

En exagérant au plus haut point, on *pourrait* estimer que c'est la plus stricte mise en application du paradigme Modèle Vue Contrôleur (cf wiki MVC) mais un projet parti sur de telles bases me semble clairement destiné à devenir rapidement ingérable