Fragen zu OOP (Objektorientierte Programmierung) - Seite 7

 
Zhunko:

Wassili, ein Beispiel, bitte!

Mir ist nur ein Fall bekannt, in dem Sie Speicher zuweisen müssen und einen Zeiger darauf benötigen.

Ich bin sicher, Sie können fast immer darauf verzichten. Es ist wünschenswert, keine manuelle Speicherverwaltung zu verwenden. Es gibt immer eine Standardbibliothek, die diese Probleme bereits gelöst hat.


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:
Das Vorhandensein einer dynamischen Typenidentifikation weist in der Regel auf die Krückenarchitektur eines Projekts hin.


Das Vorhandensein einer dynamischen Typenidentifikation deutet auf einen hohen Grad an Polymorphismus und eine höhere Abstraktionsebene hin. Sie erhöht die Verwaltbarkeit und Skalierbarkeit des Projekts. Ermöglicht die Arbeit mit Code auf der Schnittstellenebene und ermutigt den Programmierer, sich nicht mit Implementierungsdetails zu befassen.
 
Vasily, ich denke, Ihr Beispiel ist unpassend. Es gibt Vorlagen (Makros in µl), die viele Probleme zur Kompilierzeit lösen können. Und wenn Sie eine Abwärtskonvertierung vornehmen müssen, haben Sie das Programm nicht gut konzipiert (das sagte sogar Straustrup).
 
Pavlick:
Vasily, ich denke, Ihr Beispiel ist unpassend. Es gibt Vorlagen (Makros in µl), die viele Probleme bei der Kompilierung lösen können. Und wenn Sie eine Abwärtskonvertierung vornehmen müssen, haben Sie das Programm schlecht konzipiert (das sagte sogar Straustrup).

Was ist falsch an einem abwärts gerichteten Getriebe mit strenger Typenkontrolle? Straustrup hat dies gesagt, als es noch gar keine Typenkontrolle gab. Wenn Sie nun den abgeleiteten Typ kennen, können Sie die Konvertierung garantieren, bevor sie beginnt, und somit Laufzeitfehler vermeiden.

Die Vorteile der Abwärtskonvertierung liegen jedoch auf der Hand. Der wichtigste ist, dass es auf der Schnittstellenebene funktioniert. Wenn der Konstruktor einer Basisklasse im geschützten Bereich geschlossen ist, handelt es sich um eine Schnittstelle und eine abstrakte Klasse, und wir können mit ihr auf ihrer Ebene arbeiten, ohne die verfeinerte Implementierung ihrer Nachkommen kennen zu müssen. Wenn wir jedoch polymorphes Verhalten in Abhängigkeit vom Instanztyp implementieren, können wir sicherlich die Implementierung der entsprechenden Instanz angeben und z. B. ihre eindeutige Methode aufrufen. Mit virtuellen Funktionen brauchen wir nicht einmal eine Typkonvertierung. Schließlich rufen virtuelle Funktionen die spezifische Implementierung "hinter den Kulissen" auf.

 
C-4:

... Bei virtuellen Funktionen ist nicht einmal eine Typumwandlung erforderlich. Schließlich rufen virtuelle Funktionen eine bestimmte Implementierung "hinter den Kulissen" auf.


Ich habe nichts gegen den hervorgehobenen Artikel. Sie haben in dem Beispiel einen anderen Ansatz gewählt.
C-4:

Was ist falsch an dem fallenden Wurf, wenn die Typen streng kontrolliert werden?

Wenn Sie es richtig schreiben, brauchen Sie es einfach nicht.

P.S.: Ich werfe die Samapal-Typenidentifikation und den Mechanismus der virtuellen Funktionen nicht in einen Topf.

 

Ein Beispiel aus einer echten MQL-Anwendung:

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

Ich würde gerne Expertenmeinungen darüber hören, wie sie ein solches Problem lösen würden. Ich persönlich habe das Problem mit Hilfe der dynamischen Typidentifizierung, der "Mustermethode" und der Abwärtskonvertierung gelöst. Es war so gut gelöst, dass ich endlich komplexe interaktive Tabellen mit unregelmäßigen, vollständig anpassbaren Elementen erstellen konnte. Die Ergebnisse sind so greifbar, dass ich es naiv finde, zu behaupten, die "dynamische Identifizierung sei eine Krücke" und die "Abwärtskonvertierung sei böse".

P.S. Pavlick, Sie haben übrigens immer noch nicht beantwortet, was genau an der Herunterkonvertierung falsch ist.

 

Nein, ich bin weit davon entfernt, ein Experte zu sein. Was ich über das Untersetzungsgetriebe gesagt habe, ist meine Erfahrung, ich bemühe mich, es so zu schreiben, und es wird von Leuten bestätigt, die ich respektiere. Ein Programm zu schreiben, um etwas zu beweisen, ist eine Verschwendung meiner Zeit.

Pavlick, Sie haben übrigens immer noch nicht beantwortet, was genau am Downsizing schlecht ist.

Das ist schwer zu erklären. Ich verstehe, aber ich kann es nicht sagen). Die Bücher werden es wahrscheinlich besser erklären.

 
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;
      }
   }
}

Auch wenn es sich nicht um einen Fehler handelt, gibt es Vorlagen und typeid().
 
Pavlick:

Nein, ich bin weit davon entfernt, ein Experte zu sein.

Stroustrup aber schon. Und das gilt auch für viele andere. Sie sagen all die richtigen Dinge.
 
Typeid() gibt es leider nicht, und die Stärke von Vorlagen ist die statische Identifizierung. Unterschiedliche Probleme werden mit unterschiedlichen Methoden gelöst, und zu sagen, dass die eine Methode schlecht und die andere gut ist, ist eine unzulässige Unterstellung.