-4

ポリモーフィズムを示す簡単なプログラムがあります。質問: dr1.test() と dr2.test() の単純な呼び出しの上に bs->test() を使用する利点は何ですか?

#include <iostream>
using namespace std;
class base
{
public:
    virtual void test()=0;
};
class derieved1:public base
{
public:
    void test(){cout<<"Derieved 1"<<endl;}
};
class derieved2:public base
{
public:
    void test(){cout<<"Derieved 2"<<endl;}
};
int main()
{   
    derieved1 dr1;
    derieved2 dr2;
    base* bs;
    bs=&dr1;bs->test();
    bs=&dr2;bs->test();
    dr1.test();
    dr2.test();
    return 0;
}

答えてくれてありがとう。

4

4 に答える 4

3

あなたの例では、ポリモーフィズムを使用しても付加価値はありません。ポリモーフィズムは、派生クラスが何であるかわからない場合に価値をもたらします。

例えば：

void testFunction(base* tester)
{
  tester->test();
}

編集:
もちろん、付加価値が 1 つあります: ポリモーフィズムが実際に機能することを示すことです。

于 2012-06-29T15:24:36.020 に答える
2

これはばかげた質問のように思えますが、初心者から何度もこの質問を聞いたことがあります。もちろん、あなたはその例で正しいです。しかし、現実の世界では、すべてのプログラムを 1 ページに書いているわけではありません!! したがって、知っているものと知らないものに分割できる複雑なロジックがある場合に役立ちます。あなたが知っていることをコーディングして、他の人があなたが知らないことを埋められるようにフックを与えることができますが、他の人は知っていることを知っています.

旅行代理店の例を考えてみましょう。彼らは、バス会社や鉄道会社がどのようにスケジュールを組んでサービスを運営しているかを知りません。しかし、彼らはさまざまなタイプのオペレーターから最良の取引を得る方法を知っています (ただし、彼らはすべてバス/電車のオペレーターであることを忘れないでください)。だから、彼らはちょうど契約が必要です（基本クラスに相当）各バス/電車のオペレーターから特定の日付のスケジュールを取得する方法を知っています（つまり、何々の目的地の何々の日付の可能なスケジュールが必要です）。すべての事業者がこの契約を順守している限り、旅行代理店は最善を尽くすことができます。つまり、これらすべての可能なスケジュールを取得し、クライアントに最適なものを選択します。最良のものを選ぶのは旅行代理店の仕事です。バス/電車の運行者が内部でスケジュール/コストなどを維持する方法 (派生クラスの実装) を気にする必要はありません。旅行代理店はバス/電車のオペレーターとの契約のみを扱っているため、後で新しいバス/電車のオペレーターが来ても、旅行代理店のロジックを変更する必要はありません (d1.test() と dr2 を使用する場合、あなたの質問を考慮してください) .test() 新しい DerivedClass3 が追加された場合、

この種のパターンは、人生のあらゆる歩みで見られます。あなたは外食の契約を知っています。メニューを見て、食べ物を注文し、支払いをして戻ってきます（基本クラスの方法）。料理の仕方、メニューの作り方などを知る必要はありません。

つまり、ポリモーフィズムは、依存する実装の内部の詳細を知らなくても、プログラムの一部を独立して実装できる状況を実装するのに役立ちますが、インターフェースを知るだけです。

したがって、あなたの例では、どの派生クラスがあるかを気にせずに、基本クラスを使用するだけで複雑なアルゴリズムまたはロジックを実装できます。アルゴリズムのユーザーは、さまざまなタイプの派生クラスのさまざまなインスタンスを追加できますが、それでもアルゴリズムは機能します。

お役に立てれば..

于 2012-06-29T15:33:05.080 に答える
0

この特定のケースでは、ポリモーフィズムを使用すると不利になる可能性があります。呼び出しdr1.test()は静的に解決されますが、ベース ポインターを介して呼び出すと動的に呼び出しを解決できるため、オーバーヘッドが発生する可能性があります。（コンパイラがこれを最適化できるため、「できる」と言っています）。

于 2012-06-29T15:32:39.833 に答える
0

多くの場合、ポリモーフィズムには何のメリットもありません。あなたのような実験を除いて、それを使用する明確な理由が見つからない限り、おそらくポリモーフィズムを避けるべきです.

ただし、多態性を使用する明確な理由が生じます。そのような理由のほとんどは、数段落で適切に説明するのが難しいことで有名です。そのような本に示されている例は、残念なことに、まったく役に立たないという点ででっち上げられている傾向がありますが、これは完全に本のせいではありません。

オブジェクトへのポインターのコンテナー (リストやベクトルなど) は、おそらくポリモーフィズムの最も典型的なケースです。コードの一部でオブジェクトを登録して、コードの別の部分で後で使用する必要があり、そのオブジェクトのデータだけでなく動作も異なる場合は、ポリモーフィズムが役立つ可能性があります。

ポリモーフィズムの最も有用な機能の 1 つは、元のコードが設計された時点では予期されていなかった型である、既存のコードへの新しい型の追加をサポートする方法にあります。したがって、ポリモーフィズムは、多くの場合、論理的な概念よりもメンテナンスの実践の問題である可能性があります。

多くの実質的なプログラムでは、ポリモーフィズムはまったく必要ありません。また、2000 行未満のプログラムでは、ポリモーフィズムが必要になることや役立つことはめったにありません。ポリモーフィズムは、10,000 行以上のプログラムで発生する傾向がある実際の設計上の問題に対処します。これが、ポリモーフィズムの典型的な例が無駄に工夫されている傾向がある理由です。ポリモーフィズムに十分な大きさのプログラムを作成するまで、ポリモーフィズムの必要性を理解するのは本当に困難です。

于 2012-06-29T15:37:56.257 に答える