Comment éviter les anti-patterns dans iOS Apps - les nuls

Si vous utilisez le processus standard et les règles de conception orientée objet (OO) pour la création d'applications iOS, vos conceptions doivent être robustes; Cependant, même avec un processus sonore et des directives appropriées, vous pouvez créer un anti-pattern. Les anti-patterns se produisent lorsqu'une classe hérite de la fonctionnalité via une connexion inappropriée.

Même si vous êtes un développeur expérimenté, vous risquez de vous tromper gravement avec un design non fonctionnel. Ce qui suit couvre des façons spécifiques de vous tromper.

Les anti-modèles couvrent une gamme d'écueils allant du design organisationnel et de la gestion de projet à la programmation. Voici quelques anti-patterns pertinents pour la conception OO:

• L'anti-pattern Base Bean: C'est là qu'une classe hérite d'une autre classe car la superclasse contient les fonctionnalités nécessaires dans la sous-classe.

  Supposons que vous implémentiez une classe de dictionnaire dans laquelle vous pouvez rechercher les significations des mots. Une table de hachage, où les mots sont hachés pour localiser leurs significations est une structure de données raisonnable à utiliser dans un dictionnaire.

  Cependant, rendre votre dictionnaire hérité d'une table de hachage n'est pas une bonne idée. Votre dictionnaire finit par avoir des méthodes dans son interface qui n'ont aucun lien avec les mots et leurs significations. Inversement, votre classe a des méthodes qui ont tout à voir avec les dictionnaires, mais rien à voir avec les tables de hachage.

  Le bean de base se produit généralement lorsqu'un développeur de logiciel confond une relation IS-A, ce qui est approprié pour représenter une véritable sous-classe via l'héritage, avec une relation HAS-A, qui est mieux servie par une relation de confinement. En d'autres termes, un dictionnaire peut avoir une table de hachage mais n'est pas une table de hachage.

  Notez que le processus de conception OO décrit nécessite que vous essayiez de vous mettre d'accord sur une définition courte et nette pour chaque classe potentielle avant de l'élever pour devenir une classe candidate. Cela vous permet d'éviter l'anti-pattern Base Bean.

• Modèle de domaine anémique: Certains groupes, en particulier la communauté Enterprise Java, considèrent les classes de modèle de domaine comme étant simplement des getters et setters pour les attributs de la classe, sans comportement de domaine dans la classe (par exemple validations, calculs, règles métier, etc.). Ce type de conception est contraire à la pensée OO.