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

新しいコメント
 
Maxim Kuznetsov:

デザインパターン」とは、「頻繁に発生するものを同じ名前で呼ぶ」という取り決めに過ぎません。ちなみに、この言葉は建築（彫刻／橋／門／ポータルに関するもの）から来ているんだ。

似たようなことは似たような手法で解決することもあるし、そうでないこともある...。しかし、物事や方法が似ていることに同意することは、お互いを理解するために有効です。

しかし、もちろん「馬鹿にガラスの陰茎を与えれば、それを壊して自分の体を切るだろう」という人たちもいるのです。

そうそう、変数に値を代入することをKeeperやSnapshot（変数の数による：）、コードの一部を関数に入れ、値を参照で返すことをFactoryなどと呼ぶようになりましたね。

これらのパターンは、OOPの 実際の使用とは 何の関係もなく、OOPで適用される実際のパターンもないのです。

 
Igor Makanu:

勉強した」とはどういうことか？

いくつかの掲示板の説明を読むと、十数個の

MQLで適用する場合は、1つの - 戦略。

勉強した-読むだけでなく理解し、自分のためにトレーニング例を書いた。

そして、この「戦略」のパターン、どのように応用したのでしょうか？どこかで読んで、勉強して、それを応用しているのでしょうか？それとも、何か書いて書いて、見てみたら、なんと「戦略」パターンを適用していたことが判明したのでしょうか？

 
Dmitry Fedoseev:

そうそう、変数に値を代入することをガーディアンやスナップショット（変数の数による：）、参照で値を返すことをファブリコインなどと 呼ぶようになった。

これらのパターンは、OOPの 実際の使用とは 何の関係もなく、OOPで適用される実際のパターンもないのです。

まあ、どこかで不味いコニャックをたくさん飲んだんだろうけど...。

 
Dmitry Fedoseev:

何も埋め込まれていない。何パターンくらい勉強したのですか？

勉強のためではありません。BSE第31巻の全行程を知る必要はない。しかし、適切なものを開いて、興味のあるものを見つけることができます。そして、必要なところに使う。

誰かが過去に蓄積した知識（1対1のコード行ではなく、誰かが過去に発言した最適なロジック）を利用することができる。自分でバイクを発明して、自分なりの遠回りをするのもいい。また、賢い本を読んでも、そこに書かれている仮定に厳密に従わなければ、一歩も動けません。でも、それはアデプトの話であって、彼らに任せておけばいいんです。

 
Dmitry Fedoseev:

勉強した-ただ読むだけでなく、理解し、自分のために事例を書きました。

何パターンくらい勉強したのですか？
ドミトリー・フェドセーエフ

あるいは、何かを書いて、書いて、それを見て、ああ奇跡だ-「戦略」パターンを適用したことが判明した？

その逆で、最初に自分のコード構造という奇跡があり、次にパターンを勉強して、パターンに従って奇跡を一から完全に書き直し、さらに使い勝手を良くしたのです

 
Artyom Trishkin:

勉強のためではありません。BSE第31巻の全行程を知る必要はない。しかし、適切なものを開いて、興味のあるものを見つけることは可能です。そして、必要なところに使う。

誰かが過去に蓄積した知識（1対1のコード行ではなく、誰かが過去に発言した最適なロジック）を利用することができる。自分でバイクを発明して、自分なりの遠回りをするのもいい。また、賢い本を読んでも、そこに書かれている仮定に厳密に従わなければ、一歩も動けません。でも、それはアデプトの話であって、彼らに任せておけばいいんです。

これらのパターンを百科事典に例えるのは、全く不適切であり、現実的ではありません。このようなパターンでは、よく知られている「空の納屋」と「碑文」のアナロジーがより適切である。

 
Maxim Kuznetsov:

まあ、どこかで不味いコニャックでも飲んだのか...。

そう、数ページ前のこのスレッドにね。

 
Igor Makanu:
何パターンくらい勉強されたのですか？

その逆で、最初は奇跡のようなコード構造だったのが、パターンを勉強して、パターンに従って奇跡を一から完全に書き直したことで、さらに使い勝手が良くなったんです

20個か30個、出来上がった時には笑ってしまいましたよ。その後、インターネットで検索すると、さらに20件ほどのアイデアが見つかりましたが、勉強はせず、ただ笑っていました。

 
Igor Makanu:
何パターンくらい勉強されたのですか？

それどころか、まず自分のコード構造という奇跡が あり、次にパターンを勉強して、そのパターンに従って奇跡を一から完全に書き直し、さらに使い勝手が よくなったのです

という反論が必ず出てきますが、結果的に奇跡を改善する必要があったのか？

プログラミングのためのプログラミングで、同じ卵を手に入れたが、丸見えだ

 
Maxim Kuznetsov:

という反論が必ず出てきますが、結果的に奇跡を改善する必要があったのか？

Programming-for-Programming-soon-to-be-Programmedは同じ卵を得たが、フルフェイスである。

はい、その甲斐がありました

OOPは手続き型プログラミングのラッパーであるという安定した意見があり、フォーラム参加者の99%はこれに従事している。

という意見と、OOPは設計 段階でさらにコード構造を構築できるという意見が1％あり、私はこの真偽を確認中です。


と、フルフェイスで横顔を書く...。MACDのサンプルに興味がないので、ちょっとパス)))


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

20個も30個もやって、終わってみると......笑っちゃうんですよね。その後、インターネットで検索してみると、さらに20のサンプルが見つかりましたが、勉強不足で、ただ笑うだけでした。

20～30はイマイチ、そんなに問題点が思い浮かばない。


20～30パターンくらい使っている可能性もありますが......例えば、侍の刀の名前とか？- 魚の皮むきとソーセージの切り分けを同じ刀でやるのか？- せんせーい！

)))

1...454647484950515253545556575859...96
新しいコメント