OOPの専門家に質問です。 - ページ 10 1...34567891011121314151617...55 新しいコメント Georgiy Merts 2019.08.27 09:14 #91 A100: そして、私もそうです。少しずつ、少しずつ...そして、完全な理解は4-5年経ってから(そして、これは普通の人にとっては当たり前のことです)。 私の考えでは、「完全な理解」は必要ありません。要は、「本質をつかむ」ということです。 私がOOPメソドロジーを知ったのは、1995年のことでした。 私は、K&Rの精神で「普通のC」をすでに経験していましたし(古い人は覚えているはず)、アセンブラの関数もよく使っていました。プログラマーが余計な動作をしなければならないからというわけではなく、純粋にCPUの「オーバーヘッド」が原因です。しかし、すぐにこの技術の有用性を確信し、CStringクラスは 私の中で大きな「スイッチ」となりました。 それだけでなく、文字列を扱うのはもっと簡単で、当時はデータパッカーを書いていて、私のパートは入力テキスト解析でした。その結果、CStringクラスをベースに様々な文字列の階層を作るのが非常に便利だと思われたが、これはパッカーにとって重要な違いであった。 特に、データパッカーを書いた後、パッカーが本来想定していないデジタル情報を多く含む文字列に使うという課題があったことがよかったです。しかし、入力されたアルファベットを単に文字とみなしてパッキングしていたのですが、文字列がいくつかの単語と数字から構成されていることを知ることで、速度を落とすことなくパッカーを大幅に改善できました。 そこで、数字を含む文字列を表すクラス(と数字専用の圧縮器)を書き、既存のクラスにすべてを追加して、当初この機能は期待していなかったものの、新しいデータでもパッカーが動くようになったのです。 そこで、コードを修正しサポートするために、OOPの可能性を確認したのです。もちろん、CPUのオーバーヘッドはありますが、それを補って余りあるほどプログラマーの負担が軽減されます。 ですから、これからOOPを学ぼうとする人には、OOPの利点がよくわかるような作業から始めることをお勧めします。 つまり、共通の祖先を持つクラスのインスタンスを表すことになる、リスト内の異なるオブジェクトを処理するタスクで。 Georgiy Merts 2019.08.27 09:28 #92 Igor Makanu:私はこのチャンネルを購読しており、一般的に私は著者の肯定的な意見を持っていますし、議論が始まったあなたのビデオのトピックの繰り返しもあります。 私は、このビデオにあるすべての考えにほぼ完全に同意します。 異論というより、明確にしておきたいことがいくつかあります(たとえば、私はNULLはエラーを示す非常に有用なポインタだと考えていますが、関数がこのNULLポインタを返すことができることを念頭に置くべきですし、明らかに、ビデオは正しく述べています-それはオブジェクトとして扱うことはできません)。 そして、不正確さ、開発の順番、ゲッターセッター、同じNULLについては、すべて正しいのです。 作者に拍手 Реter Konow 2019.08.27 14:55 #93 哲学的でよく抽象化された人間である私が、プロが愛するプログラミングの手法を否定することに必死になるのは不思議なことです。実用的な設計であったにもかかわらず、OOPは実体が大きくなりすぎ、そのタスクが冗長になってしまった。ツールの "冗長性 "は、希少性とともにソリューションの妨げになります。そして、この冗長性は、間違いなくマーケティングの結果である。考えてみれば、コンピュータの問題の分野では、最小限のOOPですべてが解決できるのです。シンプルな関数と適切なメモリ処理ですべてが作れるように。 初期レベルでは、すぐにOOPを採用しました。すると、自分の存在の必要性を正当化できず、成長する概念の中で、タスクを抽象化した独自の生き方をしている存在に気づきました。確かにソリューションに組み込まれてはいるが、開発者の知能に寄生している。作業スピードが遅くなり、効率が悪くなる。難読化、シンタックス、ルール...などでワークフローを阻害する。それが、このソリューションの中のオプションというのが気に入らないんです。 だから、最もミニマルなOOPを使うことにしている。マーケティングする前に作られたもの。 Vladimir Simakov 2019.08.27 18:24 #94 Реter Konow: 哲学的でよく抽象化された人間である私が、プロが愛するプログラミングの手法を否定することに必死になるのは不思議なことです。実用的な設計であったにもかかわらず、OOPは実体が大きくなりすぎ、そのタスクが冗長になってしまった。ツールの "冗長性 "は、希少性とともにソリューションの妨げになります。そして、この冗長性は、間違いなくマーケティングの結果である。考えてみれば、最小限のOOPがあれば、コンピュータの問題の分野では何でも解決できる。シンプルな関数と適切なメモリ処理ですべてが作れるように。 初期レベルでは、すぐにOOPを採用しました。すると、自分の存在の必要性を正当化できず、成長する概念の中で、タスクを抽象化した独自の生き方をしている存在に気づきました。確かにソリューションに統合されるのですが、開発者の知性に寄生してしまうのです。作業スピードが遅くなり、効率が悪くなる。 難読化、シンタックス、ルール...などでワークフローを阻害する。それが、このソリューションの中のオプションというのが気に入らないんです。 だから、最もミニマルなOOPを使うことにしている。マーケティングする前に作られたもの。 例えば、あるファイルを操作するためのクラスを作成します。使い始めると、バグが出る。コードのある部分を閉じて、他の部分で何かをしようとする。2つのアプローチがあります。まず1つ目は、どこで作られたものかを常に覚えておこうとすることですが、これは1人の開発者でもなかなか難しいかもしれません。2つ目 - やるべき操作を確認するアクションの前に。さて、次のバグですが、コード中に散在する検証演算において、あちこちでタイプミスや符号の間違い、ある場所では修正したが別の場所では忘れていた、などのバグが発生しています。その結果、このような愛すべきコードの効率化から、Read/Writeメソッドなどには必ずチェックメソッドの呼び出しが含まれており、呼び出したら元に戻せるという、ほとんど使うことのない些細で単純なものになってしまったのですね。というのも、最近のハードウェアでは、解決したタスクの98%において、クロックサイクルやメモリ消費をカウントしなくて済むからです。 Georgiy Merts 2019.08.27 18:33 #95 Vladimir Simakov:例えば、あるファイルを操作するためのクラスを作成します。使い始めると、バグが出る。コードのある部分を閉じて、他の部分で何かをしようとする。2つのアプローチがあります。まず1つ目は、どこで作られたものかを常に覚えておこうとすることですが、1人の開発者でも失敗することがあります。 ピーターは得意なんです。 それが問題なのだ。ピーターは、プログラム全体から常に利用可能で、いつでも必要なものを取り出せる、すべての変数を集めた巨大なテーブルを使うのが好きなのだ。暗記のタイタンにとって、これはかなり便利なものです。 OOPでは、カプセル化はアーカイブ機能であり、コードのどこにいても、ユーザーが必要な変数だけにアクセスでき、それ以外の変数にはアクセスできないようにするために使われるだけです。しかし、Peterにとってそれはマイナスで、彼はすでにどこで、何を、どのように使ったかを覚えている。 彼は、プログラムのどの部分でも、いつでもどんな変数にもアクセスできるようにしたいのだ。彼は、変数に アクセスするためには、まずインターフェースへのポインターを取得しなければならず、インターフェースから関数を取得し、その関数が必要な値を返して初めて、私のアプローチが気に入りません。そして、これらの手順のいずれにおいても、アクセス制限に遭遇する可能性があります。というのも、もし制限があるのなら......それは理由があって入れられているのであって、重要な部分を考慮していないことになるからです。そして、ピーターにとっては、常にすべてを考慮に入れているため、邪魔な存在なのです。 Реter Konow 2019.08.27 18:45 #96 Vladimir Simakov: はい、例えばファイルを扱うクラスを作りましたね。使い始めると、エラーが出る。コードのある部分を閉じて、他の部分で何かをしようとする。2つのアプローチがあります。まず1つ目は、どこで作られたものかを常に覚えておこうとすることですが、これは1人の開発者でもなかなか難しいかもしれません。2つ目 - やるべき操作を確認するアクションの前に。さて、次のバグですが、コード中に散在する検証演算において、あちこちでタイプミスや符号の間違い、ある場所では修正したが別の場所では忘れていた、などのバグが発生しています。その結果、このような愛すべきコードの効率化から、些細で単純なことになりました。すべてのRead/Writeメソッドなどにチェックメソッドの呼び出しがあり、この呼び出しを取り消すオプションがありますが、これはほとんど使うことはないでしょう。というのも、最近のハードウェアでは、解決したタスクの98%において、クロックサイクルやメモリ消費をカウントしなくて済むからです。 逆の状況を想像してみよう。まあ、バグはないでしょうけど。なぜなら、あなたはすべてを記憶し、すべてを考慮に入れているからです。職業上の義務」というだけで、OOPを 使うか?そんなことはないだろう。じゃあ、何を気にするんだ?- コードの効率化のみ。あなたは、コードができるだけ速く動作するように、すべてのオーバーヘッドを削除しようとします。また、コードが早く開発されるような作り方を心がけるようになります。 あちこちで発生するバグについて言われると理解できますが、それがOOPの使用・不使用に関連しているとなると納得がいきません。バグの数は、自分のコードに対する知識と理解度に依存する。コードを書く人の方が、コードを差し込む人よりもよく知っている。書いている人は必ずバグが少ない。OOPはコードのポータビリティを高めるものですが、その裏返しとして、他のプログラマーに理解されにくいということがあります。それがバグの元です。 私はすべて自分で書いていますが、プロファイラやチェッカの機能がない2000行のブロックでもバグを見つけます。単純に、私は自分のコードを知っています。虫に効く最高の治療法です)) Реter Konow 2019.08.27 18:56 #97 Georgiy Merts: ピーターには効くんです。 それが問題なのだ。ピーターは、プログラム全体から常に利用可能で、いつでも必要なものを取り出せる、すべての変数を集めた巨大なテーブルを使うのが好きなのだ。暗記のタイタンにとっては、かなり便利なものです。 OOPにおけるカプセル化はアーカイブ機能であり、ユーザーがコードのどの場所でも必要な変数にだけアクセスでき、それ以上アクセスできないようにするために正確に使用されます。しかし、Peterにとってそれはマイナスで、彼はすでにどこで、何を、どのように使ったかを覚えている。 彼は、プログラムのどの部分でも、いつでもどんな変数にもアクセスできるようにしたいのだ。彼は、変数にアクセスするためには、まずインターフェースへのポインターを取得しなければならず、インターフェースから関数を取得し、その関数が必要な値を返して初めて、私のアプローチが気に入りません。そして、これらの手順のいずれにおいても、アクセス制限に遭遇する可能性があります。というのも、もし制限があるのなら......それは理由があって入れられているのであって、重要な部分を考慮していないことになるからです。そして、ピーターにとっては、常にすべてを考慮に入れているため、邪魔な存在なのです。 ジョージ 記憶力だけじゃない。母国語や英語も使って、自分にとって便利な開発環境を作っています。バイリンガルコードは、モノリンガルコードよりずっと覚えやすい。特に、標準語にとらわれず、変数を好きな名前で呼ぶことができます。実証済み。プログラミングの専門性を無視して、好き勝手に書き始めたのです。その結果、自分のコードを素早くナビゲートし、簡単に読み、思い出し、開発することができるようになったのです。さらに... ZS.私がプロ意識を持てと促していると思われないように。絶対にダメです。膨らみすぎた自我のために唾を吐いたのです。悪いことだけでなく、良いこともあることがわかった。:) Petros Shatakhtsyan 2019.08.27 19:09 #98 Реter Konow: ピーター、あなたの考え方は、チームで仕事をしたことがないようですね。大きな仕事の中で、みんながそれぞれの役割を果たし、最後にどうまとまるのかを見たことがないのでしょう。 例えば、OOPがなければ、Windowsを作り、開発することは不可能でした。 必要なければクラスも使わないようにしていたのですが、多通貨 対応ロボットにしようと思ったときに、OOPでないとどうなるかはもう明らかだったので、すぐにクラスを適用しました。 クラスを適用することで、使用するオブジェクトのペアが同じクラスであることが明白になり、同時に作業することがすでに非常に容易になります。 Реter Konow 2019.08.27 19:16 #99 Petros Shatakhtsyan: ピーター、あなたの考え方は、チームで仕事をしたことがないようですね。大きな仕事の中で、みんながそれぞれの役割を果たし、最後にどうまとまるのかを見たことがないのでしょう。 例えば、OOPがなければ、Windowsを作り、開発することは不可能でした。 必要なければクラスも適用しないようにしていましたが、多通貨 対応ロボットにしようと思ったとき、OOPがなければどうなるかはもう明らかでしたから、すぐにクラスを適用しました。 クラスを適用することで、使用するオブジェクトのペアが同じクラスであることが明白になり、同時に作業することがすでに非常に容易になります。 そうですね、チームで仕事をしたことはないです。私のやり方は、一人の開発者の実験と捉えてください。それに従うのは説得力がない。私のアプローチには大胆さがありすぎるのです(笑)。 Petros Shatakhtsyan 2019.08.27 19:37 #100 Реter Konow: そう、私はチームの一員ではなかったのです。私のやり方は、一人の開発者の実験と考えるべきでしょう。それに従えというのは説得力がない。私のやり方は不謹慎すぎるのです)。 プログラマーがFXの世界に参入する場合、プロであることやOOPを知っている必要はありません。 市場の複雑さを学び、有益な取引 戦略を立てる方がよいでしょう。そして、OOPを 使うかどうかは関係ない。Expert Advisor の収益性は、それによって損なわれることはないでしょう。 無駄なエネルギーを使わなくていいんです。 1...34567891011121314151617...55 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
そして、私もそうです。少しずつ、少しずつ...そして、完全な理解は4-5年経ってから(そして、これは普通の人にとっては当たり前のことです)。
私の考えでは、「完全な理解」は必要ありません。要は、「本質をつかむ」ということです。 私がOOPメソドロジーを知ったのは、1995年のことでした。
私は、K&Rの精神で「普通のC」をすでに経験していましたし(古い人は覚えているはず)、アセンブラの関数もよく使っていました。プログラマーが余計な動作をしなければならないからというわけではなく、純粋にCPUの「オーバーヘッド」が原因です。しかし、すぐにこの技術の有用性を確信し、CStringクラスは 私の中で大きな「スイッチ」となりました。
それだけでなく、文字列を扱うのはもっと簡単で、当時はデータパッカーを書いていて、私のパートは入力テキスト解析でした。その結果、CStringクラスをベースに様々な文字列の階層を作るのが非常に便利だと思われたが、これはパッカーにとって重要な違いであった。
特に、データパッカーを書いた後、パッカーが本来想定していないデジタル情報を多く含む文字列に使うという課題があったことがよかったです。しかし、入力されたアルファベットを単に文字とみなしてパッキングしていたのですが、文字列がいくつかの単語と数字から構成されていることを知ることで、速度を落とすことなくパッカーを大幅に改善できました。 そこで、数字を含む文字列を表すクラス(と数字専用の圧縮器)を書き、既存のクラスにすべてを追加して、当初この機能は期待していなかったものの、新しいデータでもパッカーが動くようになったのです。
そこで、コードを修正しサポートするために、OOPの可能性を確認したのです。もちろん、CPUのオーバーヘッドはありますが、それを補って余りあるほどプログラマーの負担が軽減されます。
ですから、これからOOPを学ぼうとする人には、OOPの利点がよくわかるような作業から始めることをお勧めします。 つまり、共通の祖先を持つクラスのインスタンスを表すことになる、リスト内の異なるオブジェクトを処理するタスクで。私はこのチャンネルを購読しており、一般的に私は著者の肯定的な意見を持っていますし、議論が始まったあなたのビデオのトピックの繰り返しもあります。
私は、このビデオにあるすべての考えにほぼ完全に同意します。 異論というより、明確にしておきたいことがいくつかあります(たとえば、私はNULLはエラーを示す非常に有用なポインタだと考えていますが、関数がこのNULLポインタを返すことができることを念頭に置くべきですし、明らかに、ビデオは正しく述べています-それはオブジェクトとして扱うことはできません)。
そして、不正確さ、開発の順番、ゲッターセッター、同じNULLについては、すべて正しいのです。
作者に拍手
哲学的でよく抽象化された人間である私が、プロが愛するプログラミングの手法を否定することに必死になるのは不思議なことです。実用的な設計であったにもかかわらず、OOPは実体が大きくなりすぎ、そのタスクが冗長になってしまった。ツールの "冗長性 "は、希少性とともにソリューションの妨げになります。そして、この冗長性は、間違いなくマーケティングの結果である。考えてみれば、コンピュータの問題の分野では、最小限のOOPですべてが解決できるのです。シンプルな関数と適切なメモリ処理ですべてが作れるように。 初期レベルでは、すぐにOOPを採用しました。すると、自分の存在の必要性を正当化できず、成長する概念の中で、タスクを抽象化した独自の生き方をしている存在に気づきました。確かにソリューションに組み込まれてはいるが、開発者の知能に寄生している。作業スピードが遅くなり、効率が悪くなる。難読化、シンタックス、ルール...などでワークフローを阻害する。それが、このソリューションの中のオプションというのが気に入らないんです。
だから、最もミニマルなOOPを使うことにしている。マーケティングする前に作られたもの。
哲学的でよく抽象化された人間である私が、プロが愛するプログラミングの手法を否定することに必死になるのは不思議なことです。実用的な設計であったにもかかわらず、OOPは実体が大きくなりすぎ、そのタスクが冗長になってしまった。ツールの "冗長性 "は、希少性とともにソリューションの妨げになります。そして、この冗長性は、間違いなくマーケティングの結果である。考えてみれば、最小限のOOPがあれば、コンピュータの問題の分野では何でも解決できる。シンプルな関数と適切なメモリ処理ですべてが作れるように。 初期レベルでは、すぐにOOPを採用しました。すると、自分の存在の必要性を正当化できず、成長する概念の中で、タスクを抽象化した独自の生き方をしている存在に気づきました。確かにソリューションに統合されるのですが、開発者の知性に寄生してしまうのです。作業スピードが遅くなり、効率が悪くなる。 難読化、シンタックス、ルール...などでワークフローを阻害する。それが、このソリューションの中のオプションというのが気に入らないんです。
だから、最もミニマルなOOPを使うことにしている。マーケティングする前に作られたもの。
例えば、あるファイルを操作するためのクラスを作成します。使い始めると、バグが出る。コードのある部分を閉じて、他の部分で何かをしようとする。2つのアプローチがあります。まず1つ目は、どこで作られたものかを常に覚えておこうとすることですが、これは1人の開発者でもなかなか難しいかもしれません。2つ目 - やるべき操作を確認するアクションの前に。さて、次のバグですが、コード中に散在する検証演算において、あちこちでタイプミスや符号の間違い、ある場所では修正したが別の場所では忘れていた、などのバグが発生しています。その結果、このような愛すべきコードの効率化から、Read/Writeメソッドなどには必ずチェックメソッドの呼び出しが含まれており、呼び出したら元に戻せるという、ほとんど使うことのない些細で単純なものになってしまったのですね。というのも、最近のハードウェアでは、解決したタスクの98%において、クロックサイクルやメモリ消費をカウントしなくて済むからです。
例えば、あるファイルを操作するためのクラスを作成します。使い始めると、バグが出る。コードのある部分を閉じて、他の部分で何かをしようとする。2つのアプローチがあります。まず1つ目は、どこで作られたものかを常に覚えておこうとすることですが、1人の開発者でも失敗することがあります。
ピーターは得意なんです。
それが問題なのだ。ピーターは、プログラム全体から常に利用可能で、いつでも必要なものを取り出せる、すべての変数を集めた巨大なテーブルを使うのが好きなのだ。暗記のタイタンにとって、これはかなり便利なものです。
OOPでは、カプセル化はアーカイブ機能であり、コードのどこにいても、ユーザーが必要な変数だけにアクセスでき、それ以外の変数にはアクセスできないようにするために使われるだけです。しかし、Peterにとってそれはマイナスで、彼はすでにどこで、何を、どのように使ったかを覚えている。 彼は、プログラムのどの部分でも、いつでもどんな変数にもアクセスできるようにしたいのだ。彼は、変数に アクセスするためには、まずインターフェースへのポインターを取得しなければならず、インターフェースから関数を取得し、その関数が必要な値を返して初めて、私のアプローチが気に入りません。そして、これらの手順のいずれにおいても、アクセス制限に遭遇する可能性があります。というのも、もし制限があるのなら......それは理由があって入れられているのであって、重要な部分を考慮していないことになるからです。そして、ピーターにとっては、常にすべてを考慮に入れているため、邪魔な存在なのです。
はい、例えばファイルを扱うクラスを作りましたね。使い始めると、エラーが出る。コードのある部分を閉じて、他の部分で何かをしようとする。2つのアプローチがあります。まず1つ目は、どこで作られたものかを常に覚えておこうとすることですが、これは1人の開発者でもなかなか難しいかもしれません。2つ目 - やるべき操作を確認するアクションの前に。さて、次のバグですが、コード中に散在する検証演算において、あちこちでタイプミスや符号の間違い、ある場所では修正したが別の場所では忘れていた、などのバグが発生しています。その結果、このような愛すべきコードの効率化から、些細で単純なことになりました。すべてのRead/Writeメソッドなどにチェックメソッドの呼び出しがあり、この呼び出しを取り消すオプションがありますが、これはほとんど使うことはないでしょう。というのも、最近のハードウェアでは、解決したタスクの98%において、クロックサイクルやメモリ消費をカウントしなくて済むからです。
逆の状況を想像してみよう。まあ、バグはないでしょうけど。なぜなら、あなたはすべてを記憶し、すべてを考慮に入れているからです。職業上の義務」というだけで、OOPを 使うか?そんなことはないだろう。じゃあ、何を気にするんだ?- コードの効率化のみ。あなたは、コードができるだけ速く動作するように、すべてのオーバーヘッドを削除しようとします。また、コードが早く開発されるような作り方を心がけるようになります。
あちこちで発生するバグについて言われると理解できますが、それがOOPの使用・不使用に関連しているとなると納得がいきません。バグの数は、自分のコードに対する知識と理解度に依存する。コードを書く人の方が、コードを差し込む人よりもよく知っている。書いている人は必ずバグが少ない。OOPはコードのポータビリティを高めるものですが、その裏返しとして、他のプログラマーに理解されにくいということがあります。それがバグの元です。
私はすべて自分で書いていますが、プロファイラやチェッカの機能がない2000行のブロックでもバグを見つけます。単純に、私は自分のコードを知っています。虫に効く最高の治療法です))
ピーターには効くんです。
それが問題なのだ。ピーターは、プログラム全体から常に利用可能で、いつでも必要なものを取り出せる、すべての変数を集めた巨大なテーブルを使うのが好きなのだ。暗記のタイタンにとっては、かなり便利なものです。
OOPにおけるカプセル化はアーカイブ機能であり、ユーザーがコードのどの場所でも必要な変数にだけアクセスでき、それ以上アクセスできないようにするために正確に使用されます。しかし、Peterにとってそれはマイナスで、彼はすでにどこで、何を、どのように使ったかを覚えている。 彼は、プログラムのどの部分でも、いつでもどんな変数にもアクセスできるようにしたいのだ。彼は、変数にアクセスするためには、まずインターフェースへのポインターを取得しなければならず、インターフェースから関数を取得し、その関数が必要な値を返して初めて、私のアプローチが気に入りません。そして、これらの手順のいずれにおいても、アクセス制限に遭遇する可能性があります。というのも、もし制限があるのなら......それは理由があって入れられているのであって、重要な部分を考慮していないことになるからです。そして、ピーターにとっては、常にすべてを考慮に入れているため、邪魔な存在なのです。
ジョージ 記憶力だけじゃない。母国語や英語も使って、自分にとって便利な開発環境を作っています。バイリンガルコードは、モノリンガルコードよりずっと覚えやすい。特に、標準語にとらわれず、変数を好きな名前で呼ぶことができます。実証済み。プログラミングの専門性を無視して、好き勝手に書き始めたのです。その結果、自分のコードを素早くナビゲートし、簡単に読み、思い出し、開発することができるようになったのです。さらに...
ZS.私がプロ意識を持てと促していると思われないように。絶対にダメです。膨らみすぎた自我のために唾を吐いたのです。悪いことだけでなく、良いこともあることがわかった。:)
ピーター、あなたの考え方は、チームで仕事をしたことがないようですね。大きな仕事の中で、みんながそれぞれの役割を果たし、最後にどうまとまるのかを見たことがないのでしょう。
例えば、OOPがなければ、Windowsを作り、開発することは不可能でした。
必要なければクラスも使わないようにしていたのですが、多通貨 対応ロボットにしようと思ったときに、OOPでないとどうなるかはもう明らかだったので、すぐにクラスを適用しました。
クラスを適用することで、使用するオブジェクトのペアが同じクラスであることが明白になり、同時に作業することがすでに非常に容易になります。
ピーター、あなたの考え方は、チームで仕事をしたことがないようですね。大きな仕事の中で、みんながそれぞれの役割を果たし、最後にどうまとまるのかを見たことがないのでしょう。
例えば、OOPがなければ、Windowsを作り、開発することは不可能でした。
必要なければクラスも適用しないようにしていましたが、多通貨 対応ロボットにしようと思ったとき、OOPがなければどうなるかはもう明らかでしたから、すぐにクラスを適用しました。
クラスを適用することで、使用するオブジェクトのペアが同じクラスであることが明白になり、同時に作業することがすでに非常に容易になります。
そう、私はチームの一員ではなかったのです。私のやり方は、一人の開発者の実験と考えるべきでしょう。それに従えというのは説得力がない。私のやり方は不謹慎すぎるのです)。
プログラマーがFXの世界に参入する場合、プロであることやOOPを知っている必要はありません。
市場の複雑さを学び、有益な取引 戦略を立てる方がよいでしょう。そして、OOPを 使うかどうかは関係ない。Expert Advisor の収益性は、それによって損なわれることはないでしょう。
無駄なエネルギーを使わなくていいんです。