デザインパターン？

以下の例１のようなことと、
同じ親クラスを継承することなく（例２のような形で）、実現するのは、
何というデザインパターンでしょうか？

//------------------------

◆例１：普通の実装

//データ操作の抽象クラス
Class DataManagementInterface
virtual get_data(std：：string) = 0

//データ操作（データベース） ※戻り値はデータテーブルクラス
Class DBManagement ： DataManagementInterface
virtual data_table_class get_data(std：：string)

//データ操作（ファイル） ※戻り値はファイルクラス
Class FileManagement ： DataManagementInterface
virtual file_class get_data(std：：string)

//------------------------

◆例２：インタフェースを統合するようなイメージの実装

//データ操作（データベース）
Class DBManagement
virtual void* get_data(std：：string)

//データ操作（ファイル）
Class FileManagement
virtual get_data(std：：string)

Class DataManagementInterface
virtual get_data(std::string， int 操作区分)

get_dataの実装
　　　if 操作区分が1なら、
　　　　　　DBManagementのget_data
　　　else if
　　　　　　操作区分が2なら、FileManagementのget_data

//------------------------

また、ちなみにですが、
後者の方法で、戻り値が不定(データテーブルクラスか、ファイルクラスを返す)
ことは不可能という認識ですが、「できない」で合ってますか？
.

No.2 ベストアンサー 回答者： qwertfk 回答日時： 2014/02/11 00:39

後者は条件付きディスパッチャでしょうか。

戻り値についてはvoid*等で任意型を返したりはできるのではないでしょうか。

この回答へのお礼

ありがとうございます。
void＊まではせず、親クラスのポインタでやろうと思います。
（条件付きディスパッチャを、コマンドパターンに移行しようと思います）

以下のようにしようと思います。

・準備
ファイルアクセスクラスや、データベースアクセスクラスの親となる、「データ操作クラス型のポインタ」をメンバ変数に持っておく。

・実装
(1)で用意した抽象的なハンドラで、
executeなり、runなり、getほにゃららなり、setほにゃららを実行

お礼日時：2014/02/12 09:46

No.1 回答者： hitomura 回答日時： 2014/01/31 04:14

残念ながらこれはデザインパターンではなくアンチパターンに分類されるものでしょう。

なぜならば、後者のようなコードを極力なくすためのオブジェクト指向的な解法が前者のコードだからです。

後者の場合、一連のデータ操作処理が終わるまで使う側が操作区分の値を覚えておく必要がありますが、前者の場合はどちらの処理を行うかを意識するのはデータ操作クラスのインスタンスを生成する際にだけです。

また、新たなデータ操作方法が増えた場合に、新しい方法でのデータ操作クラスの追加に加えて手を入れる必要があるのは、前者ならばクラスの生成部分だけで済みますが、後者ならば DataManagementInterface の各メソッドに広がります。

この回答へのお礼

後者のケースはアンチパターンです。

普通は、
「◆例１：普通の実装」にあるように、
抽象的な共通のインタフェースを親クラスとして設計し、
派生クラスで多様化しますよね。

そのような質問ではないのです。

//--------------------------------

「◆例１：普通の実装」ではないような、
後者のパターンを、一般的なデザインパターンに落とし込む方法は、私はうろ覚えになってしまったのですが、何個かあります。

そのパターンを思い出させて欲しいのです。
また、その実装方法（デザイン）の名前や資料を知りたいのです。
.

お礼日時：2014/02/08 03:54