記事「ソフトウェア開発とMQL5におけるデザインパターン（第１回）：作成パターン」についてのディスカッション

[MetaQuotes]

新しい記事「ソフトウェア開発とMQL5におけるデザインパターン（第１回）：作成パターン」はパブリッシュされました:

繰り返し発生する問題の多くを解決するためには、使用できる方法があります。これらの方法の使用方法を理解すると、ソフトウェアを効果的に作成し、DRY ((Do not Repeat Yourself)の概念を適用するのに非常に役立ちます。この文脈では、デザインパターンのトピックが非常に役に立ちます。なぜなら、デザインパターンは、よく説明され、繰り返される問題に対する解決策を提供するパターンだからです。

作成パターンのクラスは継承の概念を使用してクラスをインスタンスとして変更しますが、作成パターンのオブジェクトはインスタンス化のタスクを別のオブジェクトに渡します。ソフトウェアがクラスの継承よりもオブジェクトの構成に重点を置く場合、作成パターンの重要性が高まります。

作成パターンには2つの繰り返しのテーマがあると言えます。

• システムで使用できる具体的なクラスに関する知識にカプセル化の概念を使用する
• クラスのインスタンスを作成し、それらを組み合わせるメソッドを非表示にする

作成パターンは、いつ作成するかだけでなく、何を、誰が、どのように作成するかについて柔軟性を適用するのに役立ちます。

これらは、同じ実装を繰り返さずにオブジェクトを作成できるため、インスタンス化プロセスの抽象化にも役立ち、コードをより柔軟かつシンプルにするのに役立ちます。

作者: Mohamed Abdelmaaboud

[Denis Kirichenko]

翻訳者が抽象ファクトリーに関する サブセクションでちょっとしたミスをしたのかと思ったが、そうではなく、著者自身がミスをしたのだ。

Какую проблему проектирования он решает?

つまり、このテンプレートは次のような場合に使えるということだ：

• 何もない
• 独立したシステムが必要。
• 多くの製品ファミリーのうちの1つで構成されたシステムが必要である。
• 関連製品ファミリーを設計通りに一緒に使い、この制約を強制する必要がある。
• 提供されるクラスのインターフェースのみを公開し、その実装は公開しない。

このような抽象ファクトリーの使用例：

英語のソースコードでは

どのような設計上の問題を解決するのか？

つまり、次のような場合にこのパターンを使うことができる：

• 独立したシステムが必要だ。
• 多くの製品ファミリーの1つを持つ構成されたシステムが必要である。
• 関連する製品オブジェクトのファミリーを設計通りに一緒に使い、この制約を強制する必要がある。
• 提供されるクラスのインターフェースだけを明らかにし、その実装は明らかにしない。

[Rashid Umarov]

ありがとう。

[Denis Kirichenko]

もう少し不機嫌になりそうだが...。

用語の正確を期すために、記事の英語ソースを見て みる。そこで著者は、各テンプレートについて「MQL5でどう使えるか」と書いて いる。ここで注意しなければならないのは、MQL5が応用特殊言語であるということだ。では、それは何なのか？ 私たちは この教材から、MQL5でのテンプレートの使い方を本当に 学んで いるのだろうか？いいえ、MQL5におけるテンプレートの実装を見るだけです。テンプレートなのだから、まず擬似コードで記述し、それからMQL5で記述するべきだと思う。理想を言えば、MQL5 でデザインパターンを使用する実践的な例を見てみたいものだ。もしかしたら、私は先走りすぎていて、著者は各テンプレートを別の作品として検討するつもりなのかもしれない。しかし、今のところ、私たちが持っているものは......。