Question de conception de l'objectif C (iOS)

Question

J'ai un problème lorsque les données sont représentées sous la forme d'un arbre (Ex: arbre binaire). L'arbre a des nœuds de nature différente. Donc, fondamentalement, il y a une classe de base et ensuite différents noeuds en sont dérivés.

Ces données doivent également être présentées à l'écran (à l'utilisateur) et ceci implique un dessin personnalisé de chaque nœud. La façon dont le noeud est dessiné dépend du type du noeud. L'arborescence implique également un processus de simplification à l'aide duquel une nouvelle forme simplifiée de l'arborescence d'origine est dérivée sur la base de certaines règles.

Afin de dessiner ces nœuds, j'ai besoin de maintenir la position et la taille. Je voudrais savoir comment je peux séparer ce code et les données nécessaires pour dessiner l'arbre sur l'écran à partir des autres données dans le nœud qui sera utilisé pour la simplification.

J'espère que la question a eu du sens. Merci pour l'aide et le temps.

Answer 1

Ce que vous entendez par «maintenir la position et la taille» n'est pas très clair. Si vous voulez dire que donné un nœud N qui appartient à un arbre (T), il a le même parent et les mêmes enfants, vous nous préciserez si la transformation que vous appliquez au T pour obtenir le simplifié (T1) aboutit à un arbre différent ou à un arbre homomorphe.

Je ne connais pas très bien l'objectif C, mais la question que vous nous posez semble générale pour chaque langue de la POO. Étant donné N le nœud que vous utilisez dans l'arbre T, vous pouvez déclarer une classe interne "NData" dans la classe de base de N. Ainsi, chaque classe dérivée de nœud aura les données NData à utiliser dans le processus de simplification.

J'espère avoir compris la question :-)

Answer 2

Une approche consiste à créer une hiérarchie de classe 1: 1 pour les vues représentant vos nœuds d'arbre. C'est-à-dire que chaque classe de nœud d'arbre a sa propre contrepartie de sous-classe UIView qui sait comment dessiner la classe de nœud d'arbre concret. UIViews (et CALayers) ont déjà toutes les interfaces nécessaires pour maintenir les tailles, les positions et même les hiérarchies. Un inconvénient possible de cette approche est que si vous avez une énorme hiérarchie de classes de nœuds d'arbres (très nombreuses classes de nœuds), vous aurez autant de classes d'affichage, ce qui peut devenir un peu ennuyeux à coder et à supporter. Essayez d'extraire la plupart des fonctionnalités de dessin courantes dans une superclasse de vue de nœud d'arbre et voyez si cela contribue à simplifier la hiérarchie des classes de vue de nœud en réutilisant des classes d'affichage pour différents nœuds d'arbres (bien sûr, si cela a du sens).

Une autre approche consiste à ajouter des méthodes de mise en page/dessin aux classes du modèle sous la forme d'un protocole. Ainsi, vos nœuds d'arbre savent comment dessiner eux-mêmes, une seule classe de vue de nœud d'arbre appelle ces méthodes de dessin et maintient les tailles/positions. Dans les deux cas, une classe de vue de noeud a une variable d'instance référençant un modèle de noeud et peut accéder aux propriétés de noeud nécessaires pour dessiner/mettre en forme le noeud.