Шаблон проектирования Тип: Назначение: Структура: Плюсы: Минусы: Описан в Design Patterns Фабричный метод (англ. также известен как Виртуальный конструктор (англ. )) — порождающий шаблон проектирования, предоставляющий подклассам интерфейс для создания экземпляров некоторого класса. В момент создания наследники могут определить, какой...
言っておくが、やってみてくれ、猛烈にロットオブコードなんだ。インスタンス化可能なクラス「CFoo: public InterfaceCFoo」は、フィールドInterfaceCFoo *privateContext（1:1リンクを行う）を含み、ファクトリー経由で作成・削除し、すべてのメソッドをデリゲートし、CFoo*がこの<->privateContextをあちこちで参照するように変換しなければなりません。これは「手作業で夕日を落とす」、つまり継承を委任に置き換え、その場で夕日を落とすということです。
自分には自分の包みがあり、相手には相手の包みがある。MQL4よりも便利なラッパーを作ることはできないか、ということでした。
あまり選べないと思うのですが...。
個人的には、クロスプラットフォームのためにラッパーが必要なのです。
もちろん、OOPの美しさの代償として、リソースとデバッグに費やす多くの時間を支払う必要があります。OOPは、便利なテキストラッパーとして、あるいは実行時の初期化で最小限の使用しか意味がない...。実は、OOPは プログラマーの労働時間のコストを上げ、より高度な機器の購入を促すためのマイクロソフト社のマーケティングに過ぎなかったのです。しかも、彼ら自身はバカではなく、すべてのソフトウェアをC言語とアセンブラで書いている。
なんて先見の明があるんだ...。
夢想家なんですね。
この話題について、何か有意義なことはないのか？
またもや、出会ってしまった...。
MQLでは、メソッドの実装とプロトタイプを「曲がりなりにも」分離することは不可能で、ユーザー（顧客、テスター、友人/知人）に別々の*.mqhファイルと別々の*.ex4ファイル（C++の*.hと*obj/lib/dllに類似）を提供する方法はない。
またもや、出会ってしまった...。
MQLでは、メソッドの実装とプロトタイプを「不意に」分離することは不可能で、ユーザー（顧客、テスター、友人/知人）に別々の*.mqhファイルと別々の*.ex4ファイル（C++の*.hと*obj/lib/dllに類似）を提供する方法がない。
タスクについて、もう少し具体的に教えてください。クリーンなインターフェースを返すファクトリーをインポート したヘッダを提供し、その実装全体をex4の中に詰め込むのは、かなり簡単なようです。
タスクについて、もう少し具体的に教えてください。インポートファクトリーでヘッダーを提供し、クリーンなインターフェースを返し、すべての実装はex4の中に格納することが可能なようです。
クラスが記述されているmqhと、その実装が格納されているex4からなるクラスライブラリを、最小限の労力でユーザーに提供することが課題である。
これまでの唯一の選択肢は、このボトルネックを回避するために松葉杖で大量のテキストを引きずっているのです。
ex4でCFooの実装を削除するための簡単で便利な方法をご存知の方は、レシピを共有してください。
class CFoo {
public:
CFoo(); //default
CFoo(const CFoo orig); // copy
~CFoo();
bool Set(string key,CFoo & link);
CFoo *Get(string key);
bool Clear(string key);
};
タスクは、クラスが記述されているmqhと、クラスが実装されているex4からなるクラスライブラリをユーザに提供することです。
これまでの選択肢は、このボトルネックを回避するために松葉杖で大量のテキストを引っ張るだけ。
ex4でCFooの実装を削除するための簡単で便利な方法をご存知の方は、ぜひレシピを共有してください。
class CFoo {
public:
CFoo(); //default
CFoo(const CFoo orig); // copy
~CFoo();
bool Set(string key,CFoo & link);
CFoo *Get(string key);
bool Clear(string key);
};
さて、私はすでに方法を書きましたが、なぜそれが適切でないのでしょうか？ヘッダーファイルに記述された抽象クラス（インターフェース）を返すファクトリーメソッド（関数）を作るのです。実装はすべて隠蔽されています。実際の例は、例えば、私のブログの「専門家の最適化オンザフライのライブラリ（英語）」で見ることができます。
まあ、すでにメソッドを書いているのですが、それの何がいけないのでしょうか？ヘッダーファイルに記述された抽象クラス（インターフェース）を返すファクトリーメソッド（関数）を作るのです。実装はすべて隠蔽されています。実際の例は、例えば、私のブログの「専門家の最適化オンザフライのライブラリ（英語）」で見ることができます。
ソースコードを投入してみてください。そして、誰もが知っているWikiへのリンク
ソースのwikiへのリンクは大丈夫なのでは？;-)
ソースのwikiへのリンクは大丈夫なのでは？;-)
が、そうはいきません :-)
言っておくが、やってみてくれ、猛烈にロットオブコードなんだ。インスタンス化可能なクラス「CFoo: public InterfaceCFoo」は、フィールドInterfaceCFoo *privateContext（1:1リンクを行う）を含み、ファクトリー経由で作成・削除し、すべてのメソッドをデリゲートし、CFoo*がこの<->privateContextをあちこちで参照するように変換しなければなりません。これは「手作業で夕日を落とす」、つまり継承を委任に置き換え、その場で夕日を落とすということです。