Questions sur la POO (programmation orientée objet) - page 7

Nouveau commentaire
 
Zhunko:

Vasily, un exemple, s'il te plaît !

Je ne connais qu'un seul cas où vous devez allouer de la mémoire et où vous avez besoin d'un pointeur sur celle-ci.

Je suis sûr que vous pouvez presque toujours vous en passer. Il est souhaitable de ne pas utiliser la gestion manuelle de la mémoire. Il existe toujours une bibliothèque standard qui a déjà résolu ces problèmes.


enum ENUM_CLASS_TYPE
{
   CLASS_PARENT,
   CLASS_CHILD_1,
   CLASS_CHILD_2
};

class Parent
{
   public:
      ENUM_CLASS_TYPE(void){return classType;}
      virtual string GetName(){return "Base";}
   protected:
      Parent(ENUM_CLASS_TYPE type){classType = type;}
   private:
      ENUM_CLASS_TYPE classType;
};

class Child1 : public Parent
{
   public:
      Child1() : Parent(CLASS_CHILD_1){;}
      void MethodChild1(){;}
};

class Child2 : public Parent
{
   public:
      Child2() : Parent(CLASS_CHILD_2){;}
      void MethodChild2(){;}
};

int Start()
{
   Parent* parent = new Child1();
   switch(parent.GetType())
   {
      case CLASS_CHILD_1:
      {
          Child1* ch = parent;
          ch.MethodChild2();
          break;
      }
      case CLASS_CHILD_2:
      {
          Child1* ch = parent;
          ch.MethodChild2();
          break;
      }
   }
}
 
TheXpert:
La présence d'une identification dynamique des types indique généralement l'architecture béquille d'un projet.


La présence d'une identification dynamique des types indique un haut degré de polymorphisme et un niveau d'abstraction plus élevé. Il augmente la facilité de gestion et l'évolutivité du projet. Permet de travailler avec le code au niveau de l'interface et encourage le programmeur à ne pas entrer dans les détails de l'implémentation.
 
Vasily, je pense que votre exemple est hors de propos. Il existe des modèles (macros en µl), ils peuvent résoudre de nombreux problèmes au moment de la compilation. Et si vous devez faire une conversion vers le bas, vous n'avez pas bien conçu le programme (même Straustrup l'a dit).
 
Pavlick:
Vasily, je pense que votre exemple est hors de propos. Il existe des modèles (macros en µl), ils peuvent résoudre beaucoup de problèmes à l'étape de la compilation. Et si vous devez effectuer une conversion vers le bas, vous avez mal conçu le programme (même Straustrup l'a dit).

Quel est le problème d'un engrenage descendant avec un contrôle strict du type ? Straustrup a dit cela alors qu'il n'y avait aucun contrôle de type. Maintenant, si vous connaissez le type dérivé, vous pouvez garantir la conversion avant qu'elle ne commence et ainsi éviter les erreurs d'exécution.

Mais les avantages de la conversion vers le bas sont évidents. La principale est qu'elle fonctionne au niveau de l'interface. Si le constructeur d'une classe de base est fermé dans la portée protégée, il s'agit d'une interface et d'une classe abstraite et nous pouvons travailler avec elle à son niveau sans avoir à connaître l'implémentation raffinée de ses descendants. Mais si nous implémentons un comportement polymorphe en fonction du type d'instance, nous pouvons certainement spécifier l'implémentation de l'instance correspondante et, par exemple, appeler sa méthode unique. Avec les fonctions virtuelles, nous n'aurons même pas besoin de conversion de type. Après tout, les fonctions virtuelles appellent l'implémentation spécifique "en coulisse".

 
C-4:

... Avec les fonctions virtuelles, même une conversion de type ne sera pas nécessaire. Après tout, les fonctions virtuelles appellent une implémentation particulière "en coulisse".


Je n'ai rien contre celui qui est en surbrillance. Vous avez adopté une approche différente dans l'exemple.
C-4:

Qu'y a-t-il de mal à ce que la coulée tombe quand les types sont strictement contrôlés?

Si vous l'écrivez correctement, vous n'en avez pas besoin.

P.S : Je ne mets pas dans la même bouteille l'identification de type samapal et le mécanisme de fonction virtuelle.

 

Un exemple tiré d'une application MQL réelle :

Дана строка таблицы состоящая из ячеек нескольких типов. Часть из них являются обычным полями текста OBJ_TEXT, часть - кнопками OBJ_BUTTON а часть - ячейками, в которых текст можно редактировать (OBJ_EDIT). Значения введенное в ячейку типа OBJ_EDIT запоминается, и в случае его корректности формируется некий приказ, который отправляется на выполнение внешней системе. В промежутке времени между отправкой приказа и получения ответа от системы необходимо заблокировать строку таблицы таким образом, что бы все ячейки с возможностью редактирования в них текста больше не позволяли вводить в них текст. Все кнопки входящие в строку таблицы не позволяли нажимать на себя, а в целом, все ячейки в которых есть текст, должны были бы изменить его цвет на красный, сигнализируя тем самым о своей блокировке. Строки входящие в таблицу не идентичны друг другу и не содержат регулярной структуры. Одна строка может содержать кнопку, тогда как другая нет. Одна строка может содержать какой-либо столбец, а другая нет и т.д.

J'aimerais connaître l'avis d'experts sur la façon dont ils résoudraient un tel problème. J'ai personnellement résolu ce problème en utilisant l'identification dynamique des types, la "méthode des motifs" et les conversions par étapes. Il a été si bien résolu qu'il m'a finalement permis de créer des tableaux interactifs complexes avec des éléments irréguliers et entièrement personnalisables. Les résultats sont si tangibles que je trouve naïf de prétendre que "l'identification dynamique est une béquille" et que "la conversion vers le bas est un mal".

p.s. Pavlick, au fait, vous n'avez toujours pas répondu à la question de savoir ce qui ne va pas avec la down-conversion.

 

Non, je suis loin d'être un expert. Ce que j'ai dit sur le réducteur est mon expérience, je m'efforce de l'écrire ainsi + c'est confirmé par des personnes que je respecte. Écrire un programme pour prouver quelque chose est une perte de temps.

Pavlick, au fait, tu n'as toujours pas répondu à la question de savoir en quoi la réduction des effectifs est mauvaise.

C'est difficile à expliquer. Je comprends, mais je ne peux pas le dire). Les livres l'expliqueront probablement mieux.

 
C-4:
enum ENUM_CLASS_TYPE
{
   CLASS_PARENT,
   CLASS_CHILD_1,
   CLASS_CHILD_2
};

class Parent
{
   public:
      ENUM_CLASS_TYPE(void){return classType;}
      virtual string GetName(){return "Base";}
   protected:
      Parent(ENUM_CLASS_TYPE type){classType = type;}
   private:
      ENUM_CLASS_TYPE classType;
};

class Child1 : public Parent
{
   public:
      Child1() : Parent(CLASS_CHILD_1){;}
      void MethodChild1(){;}
};

class Child2 : public Parent
{
   public:
      Child2() : Parent(CLASS_CHILD_2){;}
      void MethodChild2(){;}
};

int Start()
{
   Parent* parent = new Child1();
   switch(parent.GetType())
   {
      case CLASS_CHILD_1:
      {
          Child1* ch = parent;
          ch.MethodChild2(); // Это не ошибка?
          break;
      }
      case CLASS_CHILD_2:
      {
          Child1* ch = parent;// Это не ошибка?

          ch.MethodChild2();
          break;
      }
   }
}

Même si ce n'est pas une erreur, il y a des modèles et typeid().
 
Pavlick:

Non, je suis loin d'être un expert.

Mais Stroustrup l'est. Et beaucoup d'autres le sont aussi. Vous dites toutes les bonnes choses.
 
Typeid() n'existe malheureusement pas, et la force des modèles est l'identification statique. Des problèmes différents sont résolus par des méthodes différentes et dire qu'une méthode est mauvaise et l'autre bonne est une supposition ahulte.
1234567891011
Nouveau commentaire