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

新しいコメント
 
Alexey Navoykov:

特にどの発言に根拠がないのか？

は十分あります。

この記事は、OOPの人たちからモメるために作られた投げやりな記事で、単にmqlにFP用の言語ツールがないだけなので、mqlとは関係ない。

ということで、ここで議論しても仕方がない。

 
TheXpert:

は十分あります。

この記事は、OOPの人たちから炎上するために作られた投げやりなもので、mqlには関係ありません。なぜなら、mqlにはFP用の言語ツールがないだけだからです。

ということで、ここで議論しても仕方がない。

しかし、少なくとも、間違った（軽率な）OOPの使い 方の問題点を指摘しています。 OOPを使うこと自体が万能で、コードの品質を保証してくれるという印象を初心者に与えないためにも、ここでは非常に有効だと思います。
 
TheXpert:

は十分あります。

この記事は、OOPの人たちから炎上するために作られた投げやりなもので、mqlには関係ありません。なぜなら、mqlにはFP用の言語ツールがないだけ だからです。

ということで、ここで議論しても仕方がない。

コメントは不要です。

 
Vasiliy Sokolov:
FPの支持者は、ラムダ計算が有限個の状態とその間の遷移を持つチューリング機械によって実行されること、すなわち同じカウンタ、分岐、goto命令が使用されることを意識的に忘れているのである。ですから、FPがCやC#、Javaのような古典的な言語以上のものを提供すると主張するのは、少なくとも間違っているのです。

Vasily、この記事はあなたにとって非常に有益なものです。

 
Dmitry Fedoseev:

Vasily、この記事はあなたにとって非常に有益なものです。

私はこの人の記事のスタイルがとても好きなんです。

彼の記事のスタイルが好きなので、きれいで読みやすいといいなと思います。

 
Igor Makanu:

お世辞でもなんでもなく、私は彼の文体がとても好きです。

コードはきれいで読みやすく、ぜひ自分のものにしたいと思います。

残念ながら、私はこの話を支持することはできません。記事を読んだり、コードを見たりしたわけではありません。それは、別のことだった。

 
Dmitry Fedoseev:

残念ながら、私はこの会話をサポートすることができません - 私は記事を読んでいないし、コードも見ていないのです。それは、別のことだった。

私は、MQLにおけるOOPの目的意識を明確にするために、OOPについて意見を述べることしかできません。 コードを完成させました。どんな結果になるのか、興味深かったです。

今、私は注文を扱うためのすべての関数をクラスにラップしました。そして、コードを整理し、クラスのフィールドがプライベートであるため、関数のパラメータを削除しました - 意味がありません...。全く使えないコードが送られてきました。

確かに、小さなメソッドを追加してクラスの機能を拡張できるのは便利なのですが、将来的なことを考えると ...とか、コンパイラが未使用のコードを実行ファイルに含めないことを承知で新しいメソッドを追加するとか、...。...または...もう一度書き直す - だから、全体として、我々は注文を扱うためのクラスのある種のモンスターを持っています。

すなわち、普遍性料は数ヶ月後には読めなくなるような肥大化したコードであり、そのコードを継承することで、クラスの中で何が余計なのかを見つける必要がなくなるのです - あなたの時間を無駄にしすぎましたね

原則的に、これから実行するタスクに応じたメソッド名で読むことができます。全般的に満足のいく結果ではありません。

 
Igor Makanu:

私は、MQLにおけるOOPの合理性を理解するために、OOPについての私の意見を述べることができます。 私はコードを仕上げました - それは最終的に出てくるものを見るのは面白かったです、最初は私が使用していた書き方でした - 注文で動作するサービス関数をデバッグし、私は特定のタスクでのみ使用する予定のデータや小さなメソッドを保持し、私は クラス（手続きスタイル）から注文で動作する関数を呼び出す OOPを挿入しました。

今、私は注文を扱うためのすべての関数をクラスにラップしました。そして、コードを整理し、クラスのフィールドがプライベートであるため、関数のパラメータを削除しました - 意味がありません...。全く使えないコードが送られてきました。

確かに、小さなメソッドを追加したり、クラスの機能を拡張できるのは便利ですが、将来的な利用を考えると ...とか、コンパイラが未使用のコードを実行ファイルに含めないことを承知で新しいメソッドを追加するとか、...。...または...もう一度書き直す - だから、全体として、我々は注文を扱うためのクラスのある種のモンスターを持っています。

すなわち、普遍性料は数ヶ月後には読めなくなるような肥大化したコードであり、そのコードを継承することで、クラスの中で何が余計なのかを見つける必要がなくなるのです - あなたの時間を無駄にしすぎましたね

原則的に、これから実行するタスクに応じたメソッド名で読むことができます。全般的に満足のいく結果ではありません。

要するに、うんこして迷子になったのだ。

 
Алексей Тарабанов:

要するに、「糞して出て行け」ということだ。

うーん、誰が出たんだろう？何言ってるんだ、わかったよ...夜中のコメントばかりで、何が何だかわからなくなりますね。

 
Igor Makanu:

...

また、クラスを使わないと、SymbolInfoDouble(_Symbol,SYMBOL_BID)のようなものを常に書いていると、疲れてしまうでしょう。 そんなのが毎回踊っている。カッコもアンダースコアも、capslockを押すか（そして見ずにどこかで、大文字の文字列を全部入力して打ち直す）、シフターを押し続けるか、迷うところだ。少なくとも、そこにOOPの有用性がある。少なくとも、これらの機能のためのクラスを作るのであれば、そうです - 巨大なものです。自分のために書くのであれば、問題ありません。オーダーの操作に関しては、頻繁に使う関数はそれほど多くないので、いくつかの関数をライブラリに入れればいいだけです。しかし、一般的には、まだ理想的なアプローチはありません。

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