Une question pour les experts de la POO. - page 3
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Créature.
Flore/Faune
Sous-espèces
Espèce
Famille
etc.
C'est ce que vous voulez ?
C'est un simple héritage de l'entité de base "Entity".
Mais vous pouvez aller plus loin que cela - il y a les unicellulaires/multicellulaires, et c'est tout pour les êtres vivants. Mais il y a aussi des non-vivants. Tout dépend des tâches, pour lesquelles vous devez trouver les propriétés d'un objet de base, et en hériter.
Si vous êtes vraiment fou, vous pouvez arriver aux atomes et commencer à les diviser en parties à la recherche d'un objet parent fondamental (attention - une réaction de fission peut devenir une réaction en chaîne, et vous détruirez la moitié du monde :)).
Bien. À première vue, le concept de la POO est idéal pour construire une hiérarchie. Mais comment travailler avec une hiérarchie construite par la POO ? C'est un océan de syntaxe et de complexité des transitions entre les liens en raison des droits d'accès aux classes et à leur contenu. C'est là que commence la surcharge, conséquence de la division en classes. D'une part, la POO permet de construire une hiérarchie, d'autre part, elle rend extrêmement difficile le travail avec celle-ci.
Eh bien, non. La POO permet d'accéder très facilement à n'importe quel membre de la hiérarchie à n'importe quel endroit.
Commencez par trouver votre objet de base avec les propriétés minimales requises.
Le reste des objets en hérite. Pour éviter de réinventer la roue, votre objet de base devrait hériter de la classe CObject de la bibliothèque standard. Vous pouvez ainsi créer votre propre hiérarchie d'objets sans avoir à réinventer les listes.
CObject --> CBaseObject --> votre hiérarchie.
Dans CBaseObject vous devez avoir une méthode virtuelle qui retourne cet objet. Ensuite, chacun des descendants aura cette méthode en conséquence, et elle retournera exactement l'objet descendant. La classe de base de CObject possède déjà une méthode -Type(). Si vous avez la même méthode virtuelle de CBaseObject, et qu'elle renvoie le type d'objet, vous saurez à quel objet vous avez accédé.
C'est comme une fondation de base pour tous vos objets. Et ils doivent tous être stockés dans leurs propres listes - chaque liste ne contiendra que des objets d'un seul type - poissons, animaux, humains, dieux, etc.
Autrement dit, vous devrez disposer d'une liste pour chaque sous-type. Et il doit y avoir une liste, qui contiendra les listes suivantes dans la hiérarchie. Chacune de ces listes doit également avoir des listes - encore une fois - qui sont les suivantes dans la hiérarchie. Et ainsi de suite.
C'est-à-dire que vous avez également besoin d'un objet liste de base, dans lequel vous placerez les listes requises. Et cette liste de base doit avoir une méthode Type(), et il doit y avoir une méthode qui permet de retourner tout objet stocké dans cette liste par son index. Ensuite, si cela est fait, vous aurez automatiquement une méthode dans n'importe laquelle des listes qui renvoie l'objet requis.
En général, vous devez d'abord réfléchir à votre objet de base, puis à votre objet de liste. Il n'est pas non plus nécessaire de créer des listes d'objets, elles existent déjà.
Et ensuite, c'est une question de technique. Et il suffit de connaître le type d'objet que vous recherchez. Il y aura plusieurs types dans sa hiérarchie, et chacun d'entre eux vous est connu et vous pouvez le demander et le recevoir.
Comme il me semblait, cela n'a rien à voir avec la POO dans ce cas.
Dans le cas de Peter, tous les objets du tableau sont recherchés par une clé quelconque. Et il n'y a aucune différence si vous utilisez des classes, si vous utilisez des tableaux, si vous utilisez un tas d'objets déclarés du tout.
La POO permet d'avoir une liste d'objets, dont chacun, disons, possède la méthode GetColor() - et l'utilisateur parcourt tous les objets à la recherche de la bonne couleur. Mais, si sans la POO - nous avons un tableau de structures identiques, que l'utilisateur doit connaître, pour obtenir la couleur d'où elle est nécessaire, avec la POO - l'utilisateur n'a pas besoin de savoir exactement comment et où la couleur est stockée - la méthode GetColor() de l'objet sait, où obtenir la couleur.
Ainsi, pour la POO - l'utilisateur n'a pas besoin de savoir comment et où la couleur de l'objet est stockée. Ainsi, si nous avons soudainement besoin d'ajouter un "objet pour aveugles", dans lequel la couleur est codée par des points en braille, nous pouvons facilement ajouter cet objet à notre liste et modifier uniquement sa méthode GetColor(), qui recevra le code couleur des points en braille et le renverra sous forme régulière. Pour l'utilisateur de notre liste, rien ne changera.
Si nous n'avons qu'un tableau, nous ne pouvons pas y mettre des "points en braille". Nous ne disposons pas d'un tel champ.
L'avantage de la POO est vraiment bien vu lorsque nous héritons de CObject, puis créons un tableau d'objets CArrayObj, et ensuite, en écrivant seulement une fonction de comparaison - nous obtenons immédiatement la capacité de trier rapidement et de faire une recherche binaire.
En gros, pour mon exemple ci-dessus, avec la couleur - pour la POO - nous écrivons une fonction de comparaison, obtenant la couleur par GetColor(), et nous pouvons trier nos objets par couleur, même sans savoir que nous avons la moitié des objets avec une couleur réelle et l'autre moitié avec des "points braille".Et si nous voulons ajouter un objet avec un nouveau code de couleurs, il nous suffit d'écrire la fonction GetColor(), qui mettra sa représentation des couleurs en conformité avec la norme, et lesalgorithmes de tri et de recherche déjà écrits accepteront ce nouvel objet sans problème.
En fait, la POO nous a permis d'avoir un algorithme de tri et de récupération pour des objets qui n'ont pas encore été écrits, avant même que nous ayons décidé exactement comment ils seront représentés et comment ils seront stockés.
Les avantages de la POO sont vraiment clairs, lorsque nous héritons de CObject, puis créons un tableau d'objets CArrayObj, et ensuite, en écrivant seulement la fonction de comparaison, nous obtenons un tri rapide et une recherche binaire.
C'est une mer de syntaxe et de difficultés avec les transitions entre les liens à cause des droits d'accès aux classes et à leur contenu. C'est là que commence la surcharge, conséquence de la division en classes. D'un côté, la POO vous permet de construire une hiérarchie, de l'autre, elle la rend extrêmement difficile à utiliser.
les modificateurs de droits d'accès permettent de détecter les erreurs au moment de la compilation
En général, tout ceci ne complique pas le travail avec les classes, ne l'utilisez pas, écrivez tout en public : et il sera alors plus facile de travailler avec eux.
SZZY : Beaucoup de belles phrases sur la POO, l'encapsulation et l'héritage... Tout cela est bien, mais l'avantage le plus important de la POO par rapport aux autres styles de programmation est le stockage de toutes les données (champs de la classe) et des fonctions de travail avec ces données (méthodes de la classe) en un seul endroit (classe) - en livre, c'est l'encapsulation. De plus, l'utilisation de la POO dépend de la tâche, si la tâche permet de mettre les classes à l'échelle, alors une hiérarchie sera nécessaire et il y aura des classes de base et leurs descendants - l'utiliser ou non dépend de vous.
Je dois admettre que dans le concept de la POO, l'"Objet" est présenté dans un contexte plus large que dans mon "Noyau". Mais, ce n'est pas surprenant, puisque je n'ai jusqu'à présent traité que des graphiques, et que la POO est utilisée pour un large éventail de tâches. Mon "menu" d'objets est plutôt clairsemé et à part "label", "élément", "fenêtre", il n'y a probablement pas grand chose d'autre... Cependant, pour les interfaces graphiques, je n'ai besoin de rien d'autre.
Cependant, la question de l'extension du concept d'"Objet" et de la construction d'une hiérarchie se pose désormais. Un simple noyau bidimensionnel ne peut pas accepter toute la variété des objets de la base de connaissances. Il faut donc soit créer un noyau différent pour les différents objets, soit suivre le concept de la POO.
Il s'agit en fait d'une question purement technique. Lequel est le plus efficace, lequel est le plus rapide, lequel est le plus lisible, etc...
En effet, vous pouvez simplement conserver tous les objets d'un tableau comme une liste de propriétés, parmi lesquelles se trouveront des pointeurs vers d'autres tableaux, avec d'autres objets et ainsi de suite. Ouvous pouvez utiliser explicitementla POO. L'orientation objet est invariablement présente dans les deux approches, seules les méthodes de mise en œuvre sont différentes. La même mémoire, les mêmes pointeurs, les mêmes objets, la même classification. Seule la forme du code est différente...
Je voulais en parler à Peter lorsqu'il comprendra le concept de stockage de données qui lui a été proposé.
Je vais essayer de comprendre ce concept de stockage et de manipulation des données.
Ok. (gloussements) Nous pouvons discuter en personne de ce sujet. Ou sur Skype, comme vous préférez. C'est juste que les spécificités ne sont pas dans le sujet de ce fil - ici, comme je le comprends, il s'agit juste de questions générales.