Анти-паттерны (anti-patterns), также известные как ловушки (pitfalls) — это классы наиболее часто внедряемых плохих решений проблем. Они изучаются, как категория, в случае когда их хотят избежать в будущем, и некоторые отдельные случаи их могут быть распознаны при изучении неработающих систем. Концепция также прекрасно подходит к...
Вы хотите быстро проверить торговую идею, не тратя времени на программирование? Выберите в "Мастере MQL5" нужный тип торговых сигналов, подключите модули сопровождения позиций и управления капиталом - на этом вся работа закончена. Создайте свои реализации модулей или закажите их через сервис "Работа" - и комбинируйте новые модули с уже существующими.
Прошло ровно 10 лет с публикации известной и классической в мире программирования статьи, написанной Ричардом Гэбриелом, название которой стало уже нарицательным и вынесено в заголовок моей заметки. Его статья стала настолько острой и злободневной для своего времени, что вызвала бурный всплеск обсуждений в сообществе программистов, целый ряд...
私の意見では、あなたは非常に大きな勘違いをしているようです
大きなプロジェクト（少なくとも数千行のコード）になると、クラスを使ったプログラミング（OOP）により、開発プロセスや、最も重要なデバッグプロセスを非常に簡単にコントロールできることがわかるでしょう。
それに、OOPはプロジェクトを実生活に近づけてくれます。実際、実生活では、オブジェクトのインスタンス（家、木、人、車、注文など）、つまりプロパティとメソッドのセットを扱うだけなのですから :)
OOPで何かをやってみると、それがよりエレガントで明快であることがわかるでしょう。手続き型プログラミングより簡単です
MoneyJinn:
MetaTrader 5の通常の手続き型プログラミングを使用します。
OOPは手続き型プログラミングを発展させたものです。
結局のところ、機能がなくてもやっていけることに異論はない。実際、あるところまではさらに高速です。異なるデータで同じアクションを実行するコード断片があっても問題ない。コピーを取るのはとても簡単です。
関数の繰り返し使用は、OOPに負ける。機能拡張とは、常に新しい関数を作り、その関数を様々な条件に応じて呼び出せるようにコードを設計し直すことである。正しく書かれたOOPプログラムでは、拡張はコード全体をやり直す必要のない簡単なものです。
OOPなしでプログラムを書いていて、スケーリングの問題、不必要なデータや何百もの関数の多さ、変数のランダムな重複、機能の「ホットスワップ」の必要性などで不快な思いをしないのであれば、OOPは必要ないのです。
そう、OOPのためにOOPで書いてはいけないのです、何もいいことはないのです。関数をクラスで置き換えるべきではありません。アンチパターンの 回避
OOPは「ニワ」「ラダ」のようなバグです。
MetaTrader5で通常の手続き型プログラミングを使用する。
MetaTrader 4と同様に、ここでもアクセス可能です。
MetaQuotesがそれを強調しないのが残念です。
OOPは手続き型プログラミングを発展させたものです。
OOPなしでプログラムを書いたときに、スケーリングの問題、豊富な余分なデータと数百の関数、偶然に重なった変数、機能の「ホットスワップ」の必要性などで不快な思いをしないのであれば、OOPは必要ないでしょう。
そう、OOPのためにOOPで書いてはいけないのです、何もいいことはないのです。関数をクラスに置き換える必要はありません。
100%に同意します。
なぜなら、実生活では、オブジェクト（家、木、人、機械、注文など）のインスタンス、つまりプロパティとメソッドのセットを扱うだけだからです :)
バーチャルな家、木、人を見るのと、実際にプロセッサで実行される順序でプログラムを見るのと、どちらが現実に近いでしょうか？
宗教的な問題です。そして、その選択は人それぞれです。
私の投稿は、OOP嫌いの代償を払うことになったブロックされたトピ主さんの質問に対する回答でした。
また、MT5のような製品を使いこなそうとする、あるいはMT4からMT5に乗り換えようとする一般のトレーダーへの回答として。
私の投稿は、ブロックされたトピックスターがOOPを嫌った代償を払うことになったという質問に対する回答でした。
トピックスターターのためのチェックリスト。
オブジェクト指向プログラミングとは、（この言葉を逆に読むと） オブジェクト指向のプログラミングです。あるいは、オブジェクトベースのプログラミング。
オブジェクトとは、現実の物体（例えば「機械」）や架空の物体（例えば「グレイル・ポプキン」）のパラメータや 動作を記述 するプログラムコード（通常は他のコードから分離されている）を意味します。それぞれのモノは、それ自身の命を持ち、その汁を吸って煮込むことができる。限られた "神経チャンネル "を使って、外部と通信する。- 外部アクセス可能な特殊機能のようなものです。
私の考えでは、OOPの最大の利点は、オブジェクトコードを他のコードから独立させてデバッグできることです。そして、モザイクのように、より複雑なオブジェクトを組み立てることができるのです。例えば、"woman "オブジェクトは他のオブジェクトを含むかもしれません。「機体」「着陸装置」「タンク」「コックピット」など。
MQL5 Wizardは、MQL OOPの良い例です。既製のオブジェクトからExpert Advisorを組み立てることができます。そして、これらのオブジェクトは組み合わせることができます。
OOPを支持する最も悲劇的な議論：その本質を理解した人は、OOPに夢中になる。プログラミングが簡単で、コードがより明確で構造化されているのです。
...
OOPを支持する最も不利な議論：OOPを理解する人はOOPに夢中になる。単純にプログラミングがしやすく、コードも理解しやすく、構造化されています。
確かに、OOPを使いこなすまでは、「こんなもの、混ぜてもしょうがない」と思っていました。
それを理解したら、すべてがクリアになりました。もう変数にユニークな名前を考案する必要はないんです。
変数に一意な名前を作る必要はなく、iとjのカウンターに一意な名前を作る必要もなく、この変数がヌルになっていない場所を見つけるために何千ものコードを検索する必要もないのです。プログラムを開くと、ここにオブジェクトの呼び出しがあり、ここにオブジェクトの相互作用があり、オブジェクトが何をしているのか理解したければ、オブジェクトコードに行く...と、すべてが目の前にあるのが最も重要な点です。
たしかに、OOPをマスターするまでは、そんなのくだらない、手を出す価値もない、と思えたものです。
それを理解した途端、私はすべてを捨てました。もうユニークな変数名を考案する必要はないのです。
変数に一意な名前を作る必要はなく、iとjのカウンターに一意な名前を作る必要もなく、この変数がヌルになっていない場所を見つけるために何千ものコードを検索する必要もないのです。:o)、そして最も重要なのは、すべてが手のひらのように平易で、プログラムを開くと、すべてがすぐに理解できることです、ここにオブジェクトの呼び出しがあり、ここにオブジェクトの相互作用があります、もしオブジェクトが何をするか理解したい場合は、オブジェクトコードに行くのです
+10
小さなプロジェクトにOOPを使うべきでは ない、という意見にも反論したいくらいです。
コードが少し長くなるだけで、透明性は何倍にもなります。
+10
小規模なプロジェクトでは、OOPを使う必要はない、というテーゼにも反論したいくらいです。
コードが長くなるのはわずかですが、その透明性は何倍にもなります。
ボトムアップでプログラミングすることの利便性を理解した私は、OOP支持者です。オブジェクトとのインタラクションのインターフェースから、クラスの実装まで。クラスの実装から始める人はすべて、適切なOOPで書いているわけではなく、機能的なラッパーを書いているのです。このようなラッパーは、変数や関数のための便利な名前空間を提供する以外の何ものでもありません。これが通常の図書館のやり方です。でも、この最低限でも「私はOOPで書いている」と胸を張って言える人もいますし、それはそれで正しいのですが。
OOPパラダイムを批判するのに十分な経験を積んだ熟練プログラマーや、現代のソフトウェア全体の流れの創始者がいるのです。これは古い話題で、原則的には、いつ、どこで、何が失われるのか、すべてはずっと前に細部まで議論されてきたことです。
http://blogerator.ru/page/oop_why-objects-have-failed
以下は、OOPサポーターの回答です。
http://bugtraq.ru/library/programming/objectshavenotfailed.html
C++の速度比較（小テスト） オブジェクト指向と手続き型プログラミング（＋コンパイラの違い）
https://www.mql5.com/ru/forum/132434/page3