質問: dll->getHandle(); // ここで HMODULE から カーソルを取得する } private: CDynamicLinkLibrary* dll; }; ... } ``` 方法2: 従来のやり方 ( 上記のUML風のやつ ) を namespace LibraryLoader で包んだだけ。 どれが C++ として正しいのかがわかりません。 動く・動かない ( または コンパイルが通る・通らない ) は実際に試せばいいかもしれませんが、 こういうのは慣れとかだと思うので。 自分なりに デザインパターン ( といっても ちょっとだけ。 Factory, TemplateMethod, Strategy ... となんとなく使えそうなやつだけ ) やったり、 UML を解説してるサイトをなるべく読んだり, 自分なりに組んだりしているのですが... なぜ 方法1 のように考えたかというと、 2chだったか、何でだったか忘れましたが、「それ オブジェクト指向の原則からしたらダメじゃねーか!」みたいな文章があったので、 「ああ、オブジェクト指向に『原則』ってあるんだな」と思い、 検索したところ、 単一責任の原則 ( SRP原則 ) というらしいですね。 まだ詳しくはチェックしていませんが、 「クラスを変更する理由が2つ以上存在してはならない」というやつらしいです。 それで、そういうことを紹介している記事にちょいちょい「リファクタリング」というものが出てきます。 主に Javaでの説明が多いですが、 リファクタリングしてみよう2の「フィールドの引き上げ(320)」で ``` フィールドの名前が違う場合、スーパークラスのフィールドとして使いたい名前に変更する コンパイルしてテストする スーパークラスに新しいフィールドを作成する =>フィールドがprivateならば、サブクラスから参照できるようにprotectedに変更する サブクラスのフィールドを削除する コンパイルしてテストする そのフィールドに対して「自己カプセル化フィールド(171)」の適用を検討する ``` (上記ページより) とあったので方法1を思いつきました。 ですが こういうのは条件 ( 状況とか ) によって変わりますよね。 やたらめったら Singletonパターンを適用するのはダメだし... とか。 今回の場合はどうやれば(オブジェクト指向的に)正解なのでしょうか。 やるからには出来る限り そういう原則とかを守りたいので。 言語は上記の通り C++ でお願いします。 宜しくお願い致します。
回答: 何を目的にしているかによると思います。 再利用できればとりあえずいいんじゃないのかなという気がします。 あとは、リファクタリングについても触れているので、単体テスト可能なように抽象クラスを適宜いれるとかになります。 上記のような目的を考慮すると、 HMODULEとかHANDLEとかの資源管理用のクラスとかはWindows APIを使う上ではよく使います。 ですので、CDynamicLinkLibraryみたいなクラスは用意しておいていいと思います。 CFunctionLinkerは要らない気がします。FARPROCという扱いにくいものを返されても使いにくいです。 ある程度種類ごとにAPIをまとめるという感じじゃないでしょうか? ``` namespace myapplication{ //この階層は具体的なアプリケーションの処理を行うクラスとかを置く。 class MusicPlayer public: void Play(int no); }; class ImageViewer{ public: void Show(int no); }; }//namespace myapplication namespace myapplication{ namespace mylib{ //例えばここに共通で使用するような内部実装を置くとか。 //規模によって階層と分類を増やす //上位クラスをテストしたいのであればAPI呼び出しの抽象クラスを作る //HMODULEの資源管理クラス class HModule{ }; //サウンド関係のAPIとかのラッパー class MusicApi{ }; }//namespace mylib }//namespace myapplication ```