MQL5におけるOOPに関する質問 - ページ 54

 
Dmitry Fedoseev:

https://www.mql5.com/ru/forum/85652/page52#comment_16423899 なぜ、サプライズ?

驚きではなく、不信感です。 あなたの習熟度は、このスレッドの書き込みを見れば一目瞭然です。
 
TheXpert:
このスレッドの投稿を見れば、あなたがこの問題に精通していることは一目瞭然です。

あなたはレベルの専門家ですか? ...都市型コミュニケーション。

 
TheXpert:

ええ、教えてください、タイトルが読まれても勉強したことにはなりません。"stl is a vector "であるパターンを持つSTLのようなものです。

ここに来て、頭でっかちの男の心中をぶち壊すとは。

あの男は夢を見ていたのに 君はそれに付き合ったのか?

))))

 
Igor Makanu:

どんなことを残念に思ったのですか?

どういたしまして、気に入ったならどうぞ。
 

ドミトリー・フェドセーエフ

どうしてそんなに慌てているんだ、君)

まあ、パターンが気に入らないのなら、まあ、使わなくていい。あるいは、その名前が気に入らないのなら、それを使えばいいのですが、「パターン」と呼ぶのはやめましょう。好きなように、都合のいいようにやってください。

しかし、その意味を否定するのは空しい。それを誇張するのと同じように;)

 
Dmitry Fedoseev:

あなたは、プログラミングの問題を解決するためのアルゴリズムと、いわゆる、今流行の、 OOPに特化した「デザインパターン」とを混同していますね。そして、他の多くのことを混同し、不注意に読んでしまうのです。少し前に、「構造を利用する」と書きました。でも、あの記事を読んで、私がクラス全体をコピーする機能について触れていなかったら、「大人なんだから、何でも大人しくやればいいのに、なんでわざわざ 不要な構造を扱う んだ、クラス全体をコピー する機能を提供すればいいじゃないか」という話になったでしょう。

1.このスレッドはOOPに関するものなので、混乱はしていません。

2.この構造によって、Snapshotパターンの本質は何ら変わることはないのでしょうか?

3.余計な手間がかからない。ただ、今、「余計なこと」をするのか、後でプロジェクトを 拡大・発展させるのか、どちらが多くなるかを天秤にかける必要があるのです。

4.これはどういうことかというと、スナップショットでは必要ないのです。

 
質問させてください。ローカルな意味でのパターンとは何でしょうか?ちょっと迷いますね、本当に。あるタスクのラッパーなのか、あるタスクの状態なのか。クラス、構造体、ポインター、ダイナミックスで、だいたいのことは把握できました。また、この用語がまだ浸透しておらず、定義も定まっていないことも確かです。また、適用するタイミングに条件はあるのでしょうか。フォトショップやレンダリングの場合は明確ですが、これらは時系列の 作業ではありません。それとも、私が見落としているだけで、ビジュアルレンダリングとGA VRに共通する何かがあるのでしょうか?
 
Aleksey Mavrin:

1.スレッドはOOPについてなので、混乱はしていないのですが。

2.この構造によって、Snapshotパターンの本質は何ら変わることはないのでしょうか?

3.余分な作業をする必要がない。ただ、今、「余計なこと」をするのか、後でプロジェクトを拡大・発展させるのか、どちらが多くなるかを天秤にかける必要があるのです。

4.なんだこれ、スナップショットには必要ないじゃん。

瑣末なことにとらわれている。おもしろくないんです。ここでの「Keeper」パターンの議論の要点は、カプセル化の維持を約束するようなものでありながら、各フィールドにいくつかのパブリックメソッドを作成することで実装されていることでした。一番大事なメッセージを受け取らないなんて、おかしな話だ。

 
Valeriy Yastremskiy:
そして、ローカルな意味でのパターンとは何かと聞いてみてもいいでしょうか。ちょっと迷いますね、本当に。あるタスクのラッパーなのか、あるタスクの状態なのか。クラス、構造体、ポインター、ダイナミクスと、よく理解できたと思います。また、この用語がまだ浸透しておらず、定義も定まっていないことも確かです。また、適用するタイミングに条件はあるのでしょうか。フォトショップやレンダリングの場合は明確ですが、これらは時系列の作業ではありません。それとも、私が見落としているだけで、ビジュアルレンダリングとGA VRに共通する何かがあるのでしょうか?

ここでは、すべてが明確で、具体的で、正統的です。BOOKがあるんです!このBOOKでは、これらのパターンを整理しています。デザイン パターンとかいう本です。しかし、この本だけでなく、インターネットやウィキペディアにさえ、デザインパターンに関する多くのウェブサイトがあり、主なものは、主題が公認されていることです))...そして、デザインパターンを理解しない者は平民であり、それをマスターした者は、人生をマスターしたのです!...そして、この本は、デザインパターンをマスターした者、つまり、人生をマスターした者であることを証明しています。アーメン!

 
Igor Makanu:

私は自分の意見を主張するつもりはありませんし、どこかで読んだことがあるかもしれませんが、プログラミングにおける問題は、正しいプログラム 構造と、変数の良い名前を素早く見つけることの2つだけで、あとは非常に簡単にできます。

私も本気です。

ありがとうございます、あなたのパターンを読んでみます

私は、誰かが現れる場合に備えて、待ちますが、唯一の初心者とトレーナーの質問akademvelopersの急襲のレベルで)))

その通り、正しい構造です。そのため、この構造について可能な限りの選択肢を検討し、与えられたタスクにおける長所と短所(拡張性の要件やメンテナンスなどを考慮)を分析し、最適なものを選択する必要があるのです。

そして、悪名高いパターンそのものは(正確にはどうであれ)、ここの構造の変形でもなく、脳の基準点に過ぎないのです。パターンXのタスクの記述に当てはまる問題なら、パターンXを適用すれば解決できる」という感じですが、それ以外の方法でも山ほど解決できるんです。

そして、一般的には、典型的な問題に対して、OOPの原則に従って解決するためのプログラマのヒントのようなものとして、この27の基本パターンが生まれました。ドミトリーが構造で持っているような、原理原則に従うタスクがなければ、パターンなど必要ないのです。