Interface comme une capacité ou une interface comme type

Je pense que vous sautez directement dans des interfaces, sautez des cours. Est-ce nécessaire pour votre application. avoir une interface "iObject"? Peut-être une classe racine "COBJECT" pour votre hiérarchie de classe, peut vous aider.

Il pense que le gagnant est la solution n ° 1, vous pouvez avoir un "MyObject", qu'il s'agisse d'une implémentation d'une interface ou d'une classe directe. Plus tard, vous pouvez ajouter des classes ou des interfaces supplémentaires dans votre hiérarchie de classe, comme vous le souhaitez.

Après avoir vu plusieurs applications (certaines miennes, d'autres), je pense qu'il devrait y avoir un "mon objet de racine de la hiérarchie de classe d'application personnalisée" ou "Mon interface racine de la hiérarchie de classe d'application personnalisée".

Je travaille sur la hiérarchie des cours dans mon projet et j'ai essentiellement une situation similaire comme celle que vous avez décrite dans votre question.

Disons que j'ai un objet de type base qui est une racine absolue de toutes les autres classes de ma boîte à outils. Donc, naturellement tout en dérive directement ou à travers ses sous-classes. Il existe une fonctionnalité courante que chaque classe dérivée d'objet doit fournir, mais dans certains classes de feuilles, les effets sont peu différents que chez les autres. Par exemple, chaque objet a une taille et une position pouvant être modifiées avec des propriétés ou des méthodes telles que la position = nouveau point (10, 10), largeur = 15, etc. Mais il y a des cours qui doivent ignorer le réglage d'une propriété ou la modifier en fonction de soi état intérieur. Pensez au contrôle amarré à gauche de la fenêtre mère. Vous pouvez définir une propriété de hauteur tout ce que vous aimez, mais il sera généralement ignoré car cette propriété dépendra vraiment de la hauteur du contrôle du conteneur parent (ou de la hauteur de la clientèle ou de la clientèle ou de la clientèle).

Donc, avoir une classe abstraite d'objet Mise en œuvre de la fonctionnalité commune de base est correcte jusqu'à ce que vous atteigniez un point de votre choix "personnaliser". Si l'objet fournit une méthode Protected Virtual Setethight appelée dans la séchis de la propriété de Hauteur, vous pouvez le remplacer dans votre classe DockedControl et permettre la modification de la hauteur uniquement si l'accueil n'est pas, dans d'autres cas, vous le limitez ou ignorez complètement.

Nous sommes donc heureux, mais nous avons maintenant besoin d'objet qui réagissent sur les événements de la souris comme Click ou Hover. Nous tirons donc des mouseawareObject de la classe d'objet abstrait et mettons en œuvre des événements et des trucs.

Et maintenant, le client veut des objets hauts, des objets de la souris. Alors on dérive de dockableObject et ... hmm, quoi maintenant? Si nous pouvons faire de multiples héritage, nous pouvons le faire, mais nous avons frappé un problème de diamant avec l'ambiguïté de l'interface dupliquée et nous devons y faire face. Nous pouvons avoir deux memes de types dockables et de souris de mousse dans les nouveaux appels externes de classe et de proxy pour fournir des fonctionnalités.

Et la dernière chose qui vous vient à l'esprit est de faire des interfaces iDOKABLE et d'imouseaNareware et de les laisser définir la fonctionnalité et les ajoutez librement uniquement aux objets qui doivent fournir des comportements / implémentations concrets.

Je pense que je vais diviser ma classe de base en parties et laisser mon objet avec un ensemble "noyau" très limité de propriétés et de méthodes et de repos de fonctionnalités en facultatif pour les objets comme un type mais nécessaire dans les cas de béton déplacent les interfaces Comme IRESIZABLE, IDOKABLE, IMAKEAWORLDABABETTERPABLABLE, etc. avec cette solution, il est possible de "attacher" les comportements à des classes dérivées d'objets sans avoir besoin de méthodes virtuelles virtuelles de draggin ou virtuelles pur (abstraites) de la classe de base racine jusqu'à la classe de la feuille. < / p>

Il existe bien sûr des inconvénients de la mise en œuvre d'interfaces dans toutes les classes concernées, mais vous pouvez toujours mettre en œuvre des "adaptateurs" et juste envoyer des appels vers eux. De cette façon, vous n'avez pas de mise en œuvre dupliquée (à une certaine prolongation) et que vous avez un découplage entre la réalisation de la tâche (le redimensionnement peut signifier différentes choses pour différentes classes) et l'attente du code client.

Ceci n'est probablement pas une réponse idéale pour votre question, mais peut-être que cela vous indiquera à votre propre solution.

Les classes abstraites du concept réel de types d'objets .

Interfaces abstrait le concept réel des comportements ou des capacités pour un objet .

Ainsi, les questions deviennent, est la « couleur » une propriété de l'objet ou est-il une capacité de l'objet?

Lorsque vous créez une hiérarchie que vous Contraindre le monde dans un espace plus étroit . Si vous prenez la couleur comme une propriété de l'objet, alors vous aurez deux types d'objets, ceux qui ont des couleurs et celles qui ne le font pas. Est-ce qui correspondent à votre « monde »?

Si vous le modèle comme une capacité (Interface), vous aurez des objets qui sont en mesure de fournir, permet de diffuser de dire, les couleurs au monde.

Pour la transformation de la même logique applique. Vous pouvez diviser le monde en deux types d'objets, ceux qui peuvent se transformer et ceux qui ne peuvent pas, ou vous pouvez le voir comme une capacité, un objet peut avoir la capacité de se transformer en une autre chose.

Pour moi, de ce point de vue, ce qui serait logique serait:

• La couleur est une propriété de l'objet. En fait, chaque objet doit avoir une couleur, même si sa transparence, même si est la réflexion, même si son « none » (bonne chance de trouver ce un objet avec la couleur = aucun moyen dans le monde réel, encore il pourrait être logique dans votre la logique du programme).
• La transformation est une capacité, qui est une interface, quelque chose l'objet est capable de faire , entre autres l'objet peut ou peut ne pas être en mesure de faire.