OOP(オブジェクト指向プログラミング)に関する質問 - ページ 7

 
Zhunko:

ワシリー、例を挙げてくれ!」。

メモリを確保する必要があり、そのポインタが必要なケースを1つだけ知っています。

ほとんどなくても大丈夫だと思います。手動でのメモリ管理は行わないことが望ましい。これらの問題をすでに解決している標準ライブラリが必ずあります。


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:
動的な型識別の存在は、通常、プロジェクトのクラッチ・アーキテクチャを示します。 。


動的型識別の有無は、高度なポリモーフィズムと 高い抽象度を示します。プロジェクトの管理性、拡張性を高めることができます。インターフェイスレベルでコードを扱うことを可能にし、プログラマが実装の詳細に立ち入らないように促す。
 
バシリー 君の例は、ズレてると思う。テンプレート(μlのマクロ)があり、コンパイル時に多くの問題を解決することができます。また、ダウンコンバートをしなければならないのであれば、プログラムをうまく設計できていないことになります(Straustrup氏もそう言っています)。
 
Pavlick:
バシリー 君の例は、ズレてると思う。テンプレート(μlのマクロ)があり、コンパイル段階で多くの問題を解決することができます。また、ダウンコンバートが必要な場合は、プログラムの設計が悪い(Straustrup氏もそう言っていた)。

厳格な型式管理でダウンギア化することの何がいけないのか?ストラウストラップは、型式制御が全く行われていないときに、このようなことを言ったのである。さて、派生型が分かっていれば、変換を開始する前に保証することができるので、実行時エラーを回避することができます。

しかし、ステップダウン変換のメリットは明らかです。主なものは、インターフェイスレベルで動作することです。ベースクラスのコンストラクタがprotectedスコープで閉じられている場合、それはインターフェースであり抽象クラスであるため、その子孫の洗練された実装を知らなくても、そのレベルで作業することができる。しかし、インスタンスタイプに応じたポリモーフィックな振る舞いを実装すれば、確実に対応するインスタンスの実装を指定し、例えばそのインスタンス固有のメソッドを呼び出すことができる。仮想関数を使えば、型変換も必要ない。結局のところ、仮想関数は「裏で」特定の実装を呼び出すことになる。

 
C-4:

... 仮想関数を使えば、型変換すら不要になる。結局のところ、仮想関数は「裏で」特定の実装を呼び出すことになる。


強調表示されたものには何の恨みもありません。例では違うアプローチをしていましたね。
C-4:

型が厳密に管理されているのに、フォールディングキャストで何が 悪いんだ?

正しく書けば、必要ないだけです。

追伸:サマパル型の識別と仮想関数 機構を同じ瓶に入れているわけではありません。

 

実際のMQLアプリケーションからの例です。

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

このような問題をどのように解決するのか、専門家の意見を聞いてみたい。私自身は、ダイナミック型判別、「パターン方式」のパターン、ステップダウン変換を使って解決しました。それが見事に解決され、ついに不規則でフルカスタマイズ可能な要素を持つ複雑なインタラクティブ・テーブルを作ることができるようになったのです。その成果は目に見えるもので、ド「ダイナミック識別がひつようだ」「ダウンコンバージョンが悪だ」と主張するのは甘いと思う。

p.s. ところで、パブリックさん、ダウンコンバートの何が問題なのか、まだ答えていませんね。

 

いや、専門家とは程遠いですね。減速ギアについて私が言ったことは、私の経験であり、そのように書くように努めています+私が尊敬する人々によって確認されたことです。何かを証明するためにプログラムを書くのは、私の時間の無駄です。

パブリック ところで、ダウンサイジングの何が悪いのか、まだお答えになっていませんね。

説明するのが難しいんです。わかるけど、言えない)。書籍の方が説明がわかりやすいかもしれませんね。

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

エラーでなくとも、テンプレートやtypeid()がある。
 
Pavlick:

いや、専門家とは程遠いですね。

しかし、ストルストルップはそして、他の多くの人々も同様です。いいことばかり言っていますね。
 
Typeid()は残念ながら存在せず、テンプレートの強みは静的な識別です。異なる問題は異なる方法で解決されるものであり、ある方法が悪く、他の方法が良いというのは、大げさな思い込みです。