記事「ソフトウェア開発とMQL5におけるデザインパターン(第1回):作成パターン」についてのディスカッション
翻訳者が抽象ファクトリーに関する サブセクションでちょっとしたミスをしたのかと思ったが、そうではなく、著者自身がミスをしたのだ。
Какую проблему проектирования он решает?
つまり、このテンプレートは次のような場合に使えるということだ:
- 何もない
- 独立したシステムが必要。
- 多くの製品ファミリーのうちの1つで構成されたシステムが必要である。
- 関連製品ファミリーを設計通りに一緒に使い、この制約を強制する必要がある。
- 提供されるクラスのインターフェースのみを公開し、その実装は公開しない。
このような抽象ファクトリーの使用例:
英語のソースコードでは
どのような設計上の問題を解決するのか?
つまり、次のような場合にこのパターンを使うことができる:
- 独立したシステムが必要だ。
- 多くの製品ファミリーの1つを持つ構成されたシステムが必要である。
- 関連する製品オブジェクトのファミリーを設計通りに一緒に使い、この制約を強制する必要がある。
- 提供されるクラスのインターフェースだけを明らかにし、その実装は明らかにしない。
もう少し不機嫌になりそうだが...。
用語の正確を期すために、記事の英語ソースを見て みる。そこで著者は、各テンプレートについて「MQL5でどう使えるか」と書いて いる。ここで注意しなければならないのは、MQL5が応用特殊言語であるということだ。では、それは何なのか? 私たちは この教材から、MQL5でのテンプレートの使い方を本当に 学んで いるのだろうか?いいえ、MQL5におけるテンプレートの実装を見るだけです。テンプレートなのだから、まず擬似コードで記述し、それからMQL5で記述するべきだと思う。理想を言えば、MQL5 でデザインパターンを使用する実践的な例を見てみたいものだ。もしかしたら、私は先走りすぎていて、著者は各テンプレートを別の作品として検討するつもりなのかもしれない。しかし、今のところ、私たちが持っているものは......。
- www.mql5.com
MQLを知っていて、OOPもある程度知っていて使って いるが、デザインパターンについては全く知らない者として、あなたが説明してくれたことを理解できなかったと言わざるを得ない。
私がこの記事から学び続ける方法は、あなたのコード例だけに固執し、そこからコンセプトを理解しようとすることでしょう。
私は純粋にフィードバックを共有するためにこれを書きました。
ありがとうございました。
void FactoryClient::Switch(AbstractFactory *af) { string sFactory; StringConcatenate(sFactory,sFactory,factory); int iFactory=(int)StringToInteger(sFactory); if(iFactory>0) { Print("Factory client switches the old factory ",factory," to the new one ",af); } else { Print("Factory client accepts the new factory ",af); } Delete(); factory=af; Print("Factory client saved the new factory"); Print("Factory client requests its new factory to create the Product A"); apa=factory.CreateProductA(); Print("Factory client requests its new factory to create the Product B"); apb=factory.CreateProductB(); }
この方法は理解できない。
なぜ、この2つのポインタが同じかどうかを比較できないのか:
if (factory != ap) factory = ap;
また、ドキュメントには
int StringConcatenate( string& string_var, // string to form void argument1 // first parameter of any simple type void argument2 // second parameter of any simple type ... // next parameter of any simple type );
ファクトリーは単純型ではありません。
新しい記事「ソフトウェア開発とMQL5におけるデザインパターン(第1回):作成パターン」はパブリッシュされました:
繰り返し発生する問題の多くを解決するためには、使用できる方法があります。これらの方法の使用方法を理解すると、ソフトウェアを効果的に作成し、DRY ((Do not Repeat Yourself)の概念を適用するのに非常に役立ちます。この文脈では、デザインパターンのトピックが非常に役に立ちます。なぜなら、デザインパターンは、よく説明され、繰り返される問題に対する解決策を提供するパターンだからです。
作成パターンのクラスは継承の概念を使用してクラスをインスタンスとして変更しますが、作成パターンのオブジェクトはインスタンス化のタスクを別のオブジェクトに渡します。ソフトウェアがクラスの継承よりもオブジェクトの構成に重点を置く場合、作成パターンの重要性が高まります。
作成パターンには2つの繰り返しのテーマがあると言えます。
作成パターンは、いつ作成するかだけでなく、何を、誰が、どのように作成するかについて柔軟性を適用するのに役立ちます。
これらは、同じ実装を繰り返さずにオブジェクトを作成できるため、インスタンス化プロセスの抽象化にも役立ち、コードをより柔軟かつシンプルにするのに役立ちます。
作者: Mohamed Abdelmaaboud