OOPの専門家に質問です。 - ページ 11

新しいコメント
 
Petros Shatakhtsyan:

プログラマーがFXの世界に参入する場合、プロであることやOOPを知っている必要はありません。

市場の複雑さを学び、有益な取引 戦略を立てる方がよいでしょう。そして、OOPを 使うかどうかは関係ない。Expert Advisor の収益性に影響を与えることはありません。

無駄なエネルギーを使わなくていいんです。

それが、「できる」ということです。私の友人は、コードの間違いで預金の一部を失いましたが、OOPでは間違いが起こりにくくなります。
 
Реter Konow:

ジョージ 記憶力だけじゃない。母国語はもちろん、英語も使いながら、自分にとって快適な開発環境を作っています。バイリンガルコードは、モノリンガルコードよりずっとよく記憶されます。特に、標準語にとらわれず、変数を好きな名前で呼ぶことができます。実証済み。プログラミングの専門性を無視して、好き勝手に書き始めたのです。その結果、自分のコードを素早くナビゲートし、簡単に読み、思い出し、開発することができるようになったのです。あとはご存知の通り...。

役に立たないと思う。私の場合、どんな言語でも変数の名前はほとんど瞬時に記憶から消えてしまいます。コンピューターの後ろから立ち上がっても、すでに一般的な原理しか覚えておらず、どの変数がどの場所に入力されたのかがわかりません。

ヘッダーファイルは頻繁に見る必要があるので、必要なヘッダーのmqhファイルをタブで開いておき、情報を更新する必要があるときに切り替えるのです。クラス全体（さらに複数のクラス）が1つのmqhファイルに記述されている場合、タブの助けを借りてでも、このファイル内を「ホップ」するのは困難です。

若いころは、すでに述べたように、アセンブラで書いたりもしましたが、すべての構造をメモリに残すことはできません。メモリアドレスしかなく、マクロアセンブラでできるのは、マクロサブストラクションを使って特定の領域の名前を作るのが最大です。 これも有効です。しかし、この方法ではエラーの数がはるかに多く、このようなコードのデバッグははるかに困難であることを、私はずっと前に確信しました。

上記で既に例を挙げましたが、何らかの理由でエラーが発生し、変数が不正に変更された場合です。そして、その変数はプログラム中の多くの場所からアクセスされる。エラーが発生した場所をキャッチする方法は？OOPカプセル化では、変数を変更するインターフェース関数にブレークポイントを 設定し、不正な変更が発生したらすぐに停止して、呼び出し階層によって不正な変更が行われた場所を確認する、という非常にシンプルな方法をとります。あなたのアプローチでは、すべてのコードを調べ、この変数がアクセスされるすべての場所を探し、いたるところにブレークポイントを置き、不正なものだけでなく、すべての呼び出しを分析しなければならないのです。

 
Aliaksandr Hryshyn:
それこそ、苦しむこともある。私の友人は、自分のコードのミスで預金の一部を失いましたが、OOPはエラーの可能性を低くしてくれます。

それは、プログラマーとしての能力が低いということだ。複雑なOOPの構成では、そうでない場合よりも混乱することがあります。

クラスは必要なところに適用されなければならない。プログラマーの中には、なぜか必要のないところに多くの関数を適用しようとする強迫観念を持っている人がいることに気づきました。授業でも同じようなことが起こります。

OOPを使わずにコンパクトで短いプログラムを書く代わりに、あるプログラマーはクラスや多くの関数を適用し始め、シンプルなソリューションが何キロもあるテキストになってしまいます。

 
Petros Shatakhtsyan:

プログラマーとしての能力が低いということです。複雑なOOPの構成では、そうでない場合よりも混乱することがあります。

他の条件が同じなら？とてもそうは思えません。もし構成要素の複雑さが同じなら、OOPの方がはるかに簡単に意味を理解できます。

しかし、それは「雀の上に大砲を」というルールを打ち消すものではなく、タスクが非常にシンプルでコンパクトであるところに大きなOOPの複雑さを使うのは意味がありません。

しかし、すでにここで述べたように、OOPによってクラスライブラリを構築することができ、そのライブラリは多くのプロジェクトで使用されます。

例えば、同じ配列のクラス、ファイルのクラス...。OOPを使わずにごく簡単なインジケータを書く場合でも、ファイルを扱う標準的な機能を使うよりも、CFileというクラスを 宣言してその機能を使う方がずっと簡単です。CFileをより特殊なものに簡単に置き換えることができるのは言うまでもありません。例えば、文字列に時間といくつかの追加データを自動的に挿入する機能を持つCLogFileクラス（ログファイル用）や、データを標準のiniファイルに整理し、必要に応じてそれらを読み込んで使用できるCIniFileクラスがあります。

 
Petros Shatakhtsyan:

それは、プログラマーとしての能力が低いということだ。複雑なOOPの構成では、そうでない場合よりも混乱することがあります。

クラスは必要なところに適用されなければならない。プログラマーの中には、なぜか必要のないところに多くの関数を適用しようとする強迫観念を持っている人がいることに気づきました。授業でも同じようなことが起こります。

OOPを使わずにコンパクトで短いプログラムを書く代わりに、あるプログラマーはクラスや多くの関数を適用し始め、シンプルなソリューションが何キロもある文章になってしまう。

実作業は100行で、残りの数千行はずっと前に書いてデバッグしたライブラリということでいいんでしょうか。)))
 
Vladimir Simakov:
実作業は100行で、残りの数千行は昔書いてデバッグしたライブラリということでいいんでしょうか？)))

CTrade, CAccountInfo,CPositionInfo のような既成のクラスを使っていても、そのプログラムが OOP に基づいているとは限りません。

それは、プログラマーがそのようなクラスを自分で作るのか、それとも単にそのクラスの内部（ソーステキストレベル）を知らないで使うのかによる。

 
Georgiy Merts:
....

何らかの理由で変数が不正に変更され、エラーが発生した場合です。そして、その変数はプログラム中のたくさんの場所からアクセスされる。エラー発生箇所の捕捉方法は？OOPカプセル化では、変数を変更するインターフェース関数にブレークポイントを設定し、不正な変更が発生したらすぐに停止して、呼び出し階層によって不正な変更が行われた場所を確認する、という非常にシンプルな方法をとります。そして、あなたのアプローチでは、すべてのコードを調べ、この変数への参照が発生するすべての場所を探し、あらゆる場所にブレークポイントを置き、不正なものだけでなく、すべての呼び出しを分析しなければなりません。

たしかに、私のカーネルはプログラムのすべての部分で改変されており、エラーも起こるが、ブレークポイントは必要ない。頭の中で計算し、数カ所でアラートを出して値を確認します。そうやって見つけていくんです。強調したいのは、私は自分のプログラムをよく理解しているということです。

しかし、プラス面では、この知識、構文的な障害なし、母国語ありで、私は急速に発展する膨大な機会を持っています。 だからこそ、私は自分のソリューションでOOPに反対しているのです。

コードの分割、その異質な単言語化、新しい構文、追加ルール、これらすべてがプログラムの開発を遅らせることになるのです。努力の割に結果が伴わない。これは事実として知っています。


もし私の仕事が、出来合いのコードからプログラムを作り、デバッグすることであるなら、OOPとライブラリしかないでしょう。フックアップすることと、新しいソリューションを開発することは別物です。多くの人がOOPを提唱するのは、他人のコードの塊を使い、労力を省きたいからです。私は独自の技術を使って独自のソリューションを作っており、OOPに対するニーズや見解が異なります。

 
Реter Konow:

たしかに、私のカーネルはプログラムのすべての部分で改変されており、エラーも起こるが、ブレークポイントは必要ない。頭の中で計算し、数カ所でアラートを出して値を確認します。そうやって見つけていくんです。強調したいのは、私は自分のプログラムをよく理解しているということです。

しかし、プラス面は、このような知識、構文的な障害がないこと、母国語であることから、私は急速に発展する大きなチャンスに恵まれていることです。だからこそ、私は自分のソリューションでOOPに反対しているのです。

コードの分割、その異質な単言語化、新しい構文、追加ルール、これらすべてがプログラムの開発を遅らせることになるのです。努力の割に結果が伴わない。これは事実として知っています。


もし私の仕事が、出来合いのコードからプログラムを作り、デバッグすることであるなら、OOPとライブラリしかないでしょう。フックアップすることと、新しいソリューションを開発することは別物です。多くの人がOOPを提唱するのは、他人のコードの塊を使い、労力を省きたいからです。私は独自の技術を使って独自のソリューションを作っており、OOPに対するニーズや見解が異なります。

私は、VC++のダイアログボックステンプレートを 一度は使い、MFCのCDialogをベースにアプリケーションを作り、ビジュアルモードであらゆる種類のコントロールを設定し、既製の関数を使って、OOPのパワーをすべて理解 することをお勧めします。

そして、Borland C++には、Oracleと連携するための非常に便利なクラスがあることも付け加えておきます。2012年まで一緒に仕事をしていたのですが、今はどうなんでしょう。

 
Petros Shatakhtsyan:

VC++のダイアログボックステンプレートを一度は使い、MFCのCDialogをベースにアプリケーションを作り、ビジュアルモードであらゆる種類のコントロールを設定し、既製の関数を使用することで、OOPの力をすべて理解 することをお勧めします。

そして、Borland C++には、Oracleと連携するための非常に便利なクラスがあることも付け加えておきます。2012年まで一緒に仕事をしていたのですが、今はどうなんでしょう。

この議論において、パワーとは 異なるものを意味します。あなたにとってパワーとは、すでに数多く存在するライブラリから、出来合いのコードを素早く簡単に組み立てることです。軽量化もPOWERです。でも、違うんです。新しいソリューションを開発する力ということです。ゼロから既成のコードの断片がない 開発環境で、プログラムを成長させる力。結局、グラフィカルな C++のライブラリをMQLに移植することはないのです。同じレベルのソリューションを自分で開発する必要があったのです。そして、ここで力が試されるのは、建築のスピードではなく、プログラム開発の スピードです。マークアップ言語を ゼロから自作するのに2年半かかりました。私のAPIこれは、グラフィカルなMQLライブラリ以上のものです。ビジュアルコンストラクタを作るところまで行きました。そして、その、アプローチの威力を 示す指標となるのが、このことです。ここでは誰も必要としていないのが残念です...。
 

2019年後半ですが、20日も25日も......。また、OOPを使う 必要性についても議論されるのでしょうか？

))))

気に入れば使い、気に入らなければ使わない。

以前書いた小さなサブルーチンを使ってプログラムを書くことに慣れたら......書け、寝違えたのか？このようなサブルーチンをソースコードの中に入れてしまうと、一つの大きなコードの塊になってしまいます。


オープンソースの多くの可能性を人々に与え、それはまだ同じではありません、純粋なCに機能をトリミングし、それは再び同じではありません ))))

ZS：どうせ開発者の中には、この掲示板を読んでいる人もいるのでは......と思ってしまいます。このスレッドで絶対元気になると思うんだけどな～。))))

1...456789101112131415161718...55
新しいコメント
理由: