›

Utilisation du DP Class Cluster

FloFlo Membre
12:17 modifié dans API AppKit #1
Bonjour,

venant du monde Java, on m'a toujours appris qu'il faut séparer les services proposés par une classe (son interface/protocole d'utilisation) de son implémentation via des patterns comme Factory Methods ou encore Abstract Factory. On m'a également dit qu'il fallait éviter les couplages forts du style héritage.

Du coup j'ai regardé du côté du DP Class Cluster proposé par Apple qui semble remplir ces conditions si on ne définit aucun détail d'implémentation dans la classe mère (ivars, code de méthode, ...).

Du coup je me demandai si certain avait déjà  utilisé ce genre de pattern dans ses applications et si pour vous ça a du sens de le généraliser à  toutes les classes en prévision d'un éventuel switch d'implémentation ?
Est-ce qu'il y en a qui utilise autre chose (ex: un singleton factory qui fournit les implémentations cachées derrière des protocoles) ?

Merci pour vos retours  :D

Réponses

  • FKDEVFKDEV Membre
    12:17 modifié #2
    Je voudrais pas généraliser mais, en général, cela n'a pas de sens de généraliser. :)

    Chaque pattern a son utilité. En fait chaque pattern est la solution type pour des problèmes donnés.
    Si on ne rencontre pas ces problèmes, ce n'est pas la peine de les utiliser.
    Faut pas sur-concevoir quoi...

    En l'occurence, les pattern de type factory servent à  cacher l'étape d'instanciation d'une famille de classe (cluster) afin d'éviter un couplage inutile avec les classes utilisatrices.

    Par exemple une classe Forme pourrait regrouper les rectangles, les ellipses, etc vis à  vis des classes qui pourraient les utiliser et qui seraient par exemple des classes Screen, Printer, ...

    Apple de son côté utilise plutôt le pattern pour simplifier l'API.
    Par exemple, on qu'une seule classe NSNumber alors que dans l'API, il y en a peut-être par type de nombre (int, char, float, ...).

    Donc pour moi,non, cela n'a pas de sens.
    Il y a toujours mieux à  faire qu'à  penser constamment à  une éventuelle évolution ou réutilisation future.
    Il y a peut-être 2 ou 3 reflexe a acquerir pour éviter de s'enfermer dans des conceptions non évolutives avec des classes non réutilisables mais ma première préoccupation c'est plutôt de faire simple.



  • FloFlo Membre
    12:17 modifié #3
    Oui, je suis assez d'accords avec toi, c'est à  relativiser avec les contraintes du projet (taille, changement d'implémentation sur beaucoup de classes, etc ...).

    Je crois que je vais m'en tenir à  des protocoles style Delegate et DataSource pour limiter certains couplages sans trop noyer le projet sous les couches de conception.

    En tous cas merci pour ta réponse  :)
Connectez-vous ou Inscrivez-vous pour répondre.