タグ付けされた質問 「polymorphism」

2つのクラスDogと、Cat両方がAnimalプロトコルに準拠している（Swiftプログラミング言語に関しては、Java / C＃のインターフェースになる）と考えてください。 犬と猫の混合リストを表示する画面があります。Interactor舞台裏のロジックを処理するクラスがあります。 ここで、ユーザーが猫を削除するときに確認アラートを表示します。ただし、犬はアラートなしですぐに削除する必要があります。条件付きのメソッドは次のようになります。 func tryToDeleteModel(model: Animal) { if let model = model as? Cat { tellSceneToShowConfirmationAlert() } else if let model = model as? Dog { deleteModel(model: model) } } このコードはどのようにリファクタリングできますか？それは明らかににおいがする

10 architecture  refactoring  software  architectural-patterns  polymorphism 

Itemクラスの階層があるとしましょう：Rectangle, Circle, Triangle。それらを描画できるようにしたいので、私の最初の可能性はDraw()それぞれに仮想メソッドを追加することです： class Item { public: virtual ~Item(); virtual void Draw() =0; }; ただし、コアライブラリには基本的な表現しか含まれていないのに、描画機能を別のDrawライブラリに分割したいと思います。私が考えることができるいくつかの可能性があります： 1-のDrawManagerリストを受け取り、何をすべきかを計算Itemするdynamic_cast<>ために使用する必要がある： class DrawManager { void draw(ItemList& items) { FOREACH(Item* item, items) { if (dynamic_cast<Rectangle*>(item)) { drawRectangle(); } else if (dynamic_cast<Circle*>(item)) { drawCircle(); } .... } } }; これはRTTIに依存し、1つのクラスが階層内のすべての項目を認識するように強制するため、理想的ではありません。 2-もう1つのアプローチは、描画の責任をItemDrawer階層に任せることです（RectangleDrawerなど）。 class Item { virtual Drawer* GetDrawer() …

10 c++  design-patterns  polymorphism 

したがって、私は現実の世界（学術プロジェクト以外）でのプログラミングにかなり慣れていinstanceofないため、特定のオブジェクトがどのクラスであるかを判断するために使用することは悪いことだと多くの投稿に出くわしました。 私の状況では、3つのクラスがあります。1つは基本製品クラスで、もう1つはそれを拡張し、もう1つはそれを拡張します。これらはすべてデータベースの同じテーブルに格納されており、データを取得するためにそれぞれのメソッドを使用する必要があるコードがいくつかあります。 この方法で回避するためのベストプラクティスは何ですか？ポリモーフィズムについていくつか読んだことがありますが、私が抱えている問題を解決する例は見つかりません。通常、これらはすべて、異なるオブジェクトから異なるものをプルする必要があるため機能しないメソッドをオーバーライドします。 これを行うためのより良い方法はありinstanceofますか、それともオブジェクトに固有のフィールドを取得するための使用または何らかの反射で立ち往生していますか？

10 java  programming-practices  polymorphism 

Zend Framework 1とDoctrine2をORMレイヤーとして使用して、PHPでアプリケーションを構築しています。すべて順調です。さて、私はたまたまZF1とDoctrine2の両方が独自のキャッシング実装に付属していて、それに依存していることに気付きました。私は両方を評価しましたが、それぞれに独自の長所と短所がありますが、どちらも私の単純なニーズに対して他のものより優れているとは言えません。どちらのライブラリも、実装ではなく、それぞれのインターフェイスに対して作成されているようです。 これが問題であると感じる理由は、アプリケーションのブートストラップ中に、2つのキャッシュドライバーを構成する必要があることです。それぞれに独自の構文があります。この方法でミスマッチが簡単に作成され、このため、キャッシュバックエンドへの2つの接続を設定するのは非効率的です。 今後の最善の方法を決定するつもりであり、あなたが提供できるかもしれないあらゆる洞察を歓迎します。 これまでに考えたのは、4つのオプションです。 何もせず、キャッシング機能を提供する2つのクラスが存在することを受け入れます。 ZendのインターフェースをDoctrineのキャッシング実装に固定するFacadeクラスを作成します。 オプション2、その逆-Fendを作成して、DoctrineのインターフェースをZend Frameworkバックエンドにマッピングします。 multiple-interface-inheritanceを使用して、すべてをルール化する1つのインターフェースを作成し、重複がないことを祈ります（つまり、両方に「save」メソッドがある場合、PHPのために同じ順序でパラメーターを受け入れる必要があります。適切な多型の欠如）。 どのオプションが最適ですか、または「上記のどれにも当てはまらない」のバリエーションがありません。

9 php  architecture  third-party-libraries  polymorphism 

コンパイル時のポリモーフィズムと実行時のポリモーフィズムの実際の制限を理解していると思います。しかし、明示的なインターフェイス（実行時の多態性、つまり仮想関数とポインタ/参照）と暗黙的なインターフェイス（コンパイル時の多態性、つまりテンプレート）の概念的な違いは何ですか。 私の考えでは、同じ明示的インターフェースを提供する2つのオブジェクトは同じタイプのオブジェクトである（または共通の祖先を持っている）必要がありますが、同じ暗黙的インターフェースを提供する2つのオブジェクトは同じタイプのオブジェクトである必要はありません。両方が提供するインターフェースは、まったく異なる機能を持つことができます。 これについて何か考えはありますか？ また、2つのオブジェクトが同じ暗黙のインターフェイスを提供する場合、これらのオブジェクトがそのインターフェイスを宣言する基本オブジェクトから継承しないようにする理由（仮想関数ルックアップテーブルなどの動的ディスパッチが不要であるという技術的な利点以外）それを明示的なインターフェースにしていますか？別の言い方をすると、同じ暗黙のインターフェースを提供する（したがって、サンプルテンプレートクラスの型として使用できる）2つのオブジェクトが、そのインターフェースを明示的にする基本クラスから継承しないようにできますか？ 関連する投稿： https://stackoverflow.com/a/7264550/635125 https://stackoverflow.com/a/7264689/635125 https://stackoverflow.com/a/8009872/635125 この質問をより具体的にする例を次に示します。 暗黙的なインターフェース： class Class1 { public: void interfaceFunc(); void otherFunc1(); }; class Class2 { public: void interfaceFunc(); void otherFunc2(); }; template <typename T> class UseClass { public: void run(T & obj) { obj.interfaceFunc(); } }; 明示的なインターフェース： class InterfaceClass { public: virtual void …

9 templates  interfaces  polymorphism  duck-typing  explicit 

Haskellの型クラスとGoのインターフェースに違いがあるかどうか疑問に思っています。タイプに必要な関数が値に定義されている場合、どちらも関数に基づいてタイプを定義します。つまり、値はタイプに一致します。 違いはありますか、またはこれは同じものの2つの名前だけですか？

8 haskell  type-systems  polymorphism  go 

1つのパッケージに3つのセンサーがあり、すべてを調整する必要があります。これらをsens1、sens2、およびsens3と呼びます。sens1とsens2のキャリブレーションは同じですが、sens3のキャリブレーションには追加のパラメーターが必要です。私の質問は、「読みやすさを維持しながら、ほぼ同一の3つのオブジェクトを処理する最良の方法は何ですか？」です。 もちろん、最初に考えたのは、ポリモーフィズムを使用することでした。汎用のSensorオブジェクトを.calibrate（Parameters params）メソッドでセットアップします。ここで、Parametersクラスを使用すると、実行しているキャリブレーションに基づいてパラメーターの数を変更できます。ただし、これにより次のようになります。 Sensor sens1 = new Sensor(); Sensor sens2 = new Sensor(); Sensor3 sens3 = new Sensor3(); 将来の人々は、1つのセンサーが他の2つのセンサーと根本的に異なることを知る必要がありますが、非常によく似ているため、Sens1とSens2を名前だけでサブクラス化するのが最善のようです。言い換えると、より論理的なクラス名を持たせるために、動作を変更または拡張しない2つのサブクラスを作成します。これらの3つのセンサーはすべて同じパッケージに含まれているため、このデータは非常に頻繁に組み合わされます。これにより、上記のコードが次のように変更されます。 Sensor1 sens1 = new Sensor1(); Sensor2 sens2 = new Sensor2(); Sensor3 sens3 = new Sensor3(); どこ Sensor1 extends Sensor { } Sensor2 extends Sensor { } Sensor3 extends Sensor { @Override …

8 code-smell  polymorphism