ラウンジでPLOについて語る - ページ 11 1...456789101112131415161718...23 新しいコメント Artyom Trishkin 2018.01.14 11:06 #101 Andrei:OOPにおけるジェスチャーの量は原理的に少なくできない。なぜなら、これらのインターフェースはすべて追加のオーバーヘッドであり、ロジックそのものを書くコストを上回ることが多いからである。そして、どんな機能もすでにインターフェイスを持っているにもかかわらず、つまり、本質的に意味のない別の庭を作ることが提案されているのです。 同時に、インターフェースと機能の両方で、コードを変更すると、一方が他方にフックされるため、非常に複雑になり、少なくとも2次関数的にバグの可能性が増え、労働集約的になる...ということです。当たり前といえば当たり前なんですけどね。 端末は、あなたのコードとの関係では、クラスです。端末のコードにある、自分からは見えない、パブリックメソッド（プログラムを実装するための関数）しか提供されていないものを、変更する必要が出てくることはよくあることです。 fxsaber 2018.01.14 11:10 #102 Andrei:OOPにおけるジェスチャーの量は原理的に少なくできない。なぜなら、これらのインターフェースはすべて追加のオーバーヘッドであり、ロジックそのものを書くコストを上回ることが多いからである。そして、どんな関数もすでにインターフェースを持っているにもかかわらず、つまり、本質的に役に立たないヘッジをまた作らなければならないのです。 この場合、インターフェースと機能の両方を変更すると、一方が他方にフックされるため、コードの変更が非常に複雑になり、バグの可能性と労力が少なくとも2次関数的に増加する...当たり前といえば当たり前なんですけどね。 トレーディング、自動売買システム、トレーディング戦略のテストに関するフォーラム バックヤードでOOPについて語る fxsaber さん 2018.01.14 11:35 プログラミングそのものは、プロダクションの特殊なケースである。O OPの考え方は、どんなものでも原則的に制作するものです。だから、プログラミングの話をするのは非常に狭量です。OOPは、プログラミングに登場する以前から応用に成功していたのです。産業の歴史は、コンベア化の次の段階として、オブジェクト指向の「PRODUCTION」に行き着いた。だから、OOプログラミングを語るのは、視野が狭いのです。OOソーイングブーツの話とか。私たちが話しているのは、あらゆる生産物の組織化に対するアルゴリズム的なアプローチであり、非常に特殊なケースとして、ソフトウェアの作成も含まれます。OOP生産は、従来の組立ラインに対する優位性を競技会で証明しました。今、必要な時に必要なものを作るという、短期的な生産計画があります。そして、長期的なものがあります - あなたが現時点で多くの "余分な "を置くとき、しかし、この基礎は、生産の容易なスケーリングを容易にします。繰り返しになりますが、これはプログラミングの話ではなく、制作における一般的なアプローチの話です。OOPのアプローチは、現代の権力機関の中にも見られる。 Andrei01 2018.01.14 11:11 #103 Artyom Trishkin: 端末は、あなたのコードとの関係では、クラスです。端末のコードを変更する頻度はどのくらいですか？この例は誤りです。プログラム内のインターフェースの話です... Andrei01 2018.01.14 11:15 #104 fxsaber: 産業の歴史は、コンベア化の次のステップとして、オブジェクト指向の「PRODUCTION」に行き着いた。 また、OOプログラミングには処理パイプラインがあり、OOPは抽象化の別のレイヤーを導入し、個々のコンベアや生産全体のオーバーヘッドを増加させるだけです。 fxsaber 2018.01.14 11:25 #105 Andrei:OOプログラミングにも処理コンベアがあり、OOPは別の抽象化レベルを導入し、個々のコンベアと生産全体のオーバーヘッドを増加させるだけである。あなたは愚かです、残念ながら。業界の歴史と、その中の一つのステージとして、身の回りのあらゆる物質的（だけでなく）なものに大きな役割を果たしたOOPについて語られます。そして、あなたはプログラミングの特殊な例について話し続けています。人間形成の歴史に対する無知。直系の子孫の記憶に痕跡を残さない。 Andrei01 2018.01.14 11:32 #106 fxsaber:業界の歴史と、その中の一つのステージとして、身の回りのあらゆる物質（だけでなく）において大きな役割を果たしてきたOOPについて語られます。 PLOを産業の歴史に引きずり込もうとするあなたの素朴な試みは、面白いけれども、悲しいほど無教養です。 Georgiy Merts 2018.01.14 12:10 #107 Andrei:この例は誤りです。プログラム内のインターフェイスの話です...なぜ「不正解」なのか？ プログラムは、コンピュータ上で動作するすべてのソフトウェアとどのように違うのですか？ 結局のところ、どのユーザープログラムでも同じような命令とデータセットが並んでいるのです。なぜ、ソフトウェアのある部分が、確立された交換プロトコルを介する以外に、ソフトウェアの別の部分にアクセスすることができないのですか？大丈夫、真面目にプログラミングしていれば、遅かれ早かれアクセス権の差別化の必要性に行き着くはずです。私も、リアルモードからセキュアモードに切り替えたころは、物理的なメモリアドレスにアクセスできないことが嫌でした。DMAコントローラで、保護されたシステム領域から自分の領域にデータをコピーして捻じ込んだこともありました（何をコピーしているのかがわかりにくいので、割愛）。 若い頃は、「どうして直接アクセスできないんだ、権利の侵害に近い」と憤慨していましたが......。また、何かを利用できないようにするプログラムはどうでしょうか？ まあ、経験を積んでいくと、アクセス権の差別化はプログラマー自身にとってもありがたいことで、書いたモジュールのミスを防いでくれることが多いんです。クラスを取って、それを使いたいのに、あるデータにアクセスできない...。憤慨して、どうしてそうなるのか、調べ始めると...。と、おっと...。データには直接アクセスできない「間接経路」があり、直接アクセスすると無効なデータを取得する可能性があるというシステム構成になっているなど、考慮しなければならない点があります。しかし、有効なデータを得ることもできる。すべてはその時点に依存するのだ。そして、そのようなエラーは非常に発見しにくい。ここで、最も単純な問題は、キャッシュ内のデータへのアクセスである。キャッシュされたデータが必要で、直接アクセスする場合 - 正しいデータが得られるかどうか、確信が持てますか？差別化のない手続き的なアプローチでは、使えるときと使えないとき、データが有効なときとそうでないときを理解しなければならない......。OOPアプローチでは、すべてが非常にシンプルで、キャッシュデータにはアクセスできず、関数を呼び出す だけで、必要なデータを返し、それが無効であれば有効なデータを取得することができるのです。では、このキャッシュを作成してから1年後に使うことを想像してみてください。キャッシュリフレッシュと有効性定義の原則を完全に忘れてしまったとき。OOP-approachでは、気にすることはありません。クラス機能ですべてまかなえます。しかし、関数型アプローチでは、いつ、どのようにキャッシュが更新され、その中のデータがいつ有効で、いつ無効なのかを詳細に覚えておく必要があります。 Artyom Trishkin 2018.01.14 12:35 #108 Andrei:この例は誤りです。プログラム内のインターフェイスの話です... これ以上ないくらい正しい、ヒエラルキーなのです。あなたのプログラムは、OOPのアプローチで、クラスのパブリックメソッドを見て、その構成要素を考えずに使っているのです。標準的な言語機能を使うのと同じようにね。プログラムを変更する際に、クラスを変更する必要はありません。手続き型アプローチの場合、言語の標準的な機能を変更する必要がないのと同じようにです。 Alexey Volchanskiy 2018.01.14 13:54 #109 Artyom Trishkin: 端末は、あなたのコードとの関係では、クラスです。あなたには隠されていて、パブリックメソッド（プログラムを実装するための関数）しか提供されていない端末のコードで、何かを変更する必要があることはよくあることでしょう。+++ ))) Yuriy Asaulenko 2018.01.14 14:19 #110 Artyom Trishkin: 端末は、あなたのコードとの関係では、クラスです。端末のコードの中で、自分には隠されていて、プログラムを実装するための関数であるパブリックメソッドだけが提供 されているものを変更する必要があることはよくあることです。そのようなニーズは定期的に発生します。あくまでも開発者が行うことが望ましい。簡単な例です。何らかの理由で、開発者はインジケータ・チャートの水平座標グリッドを提供する必要がないと考えた。もちろん、そのための適切な方法も提示されていない）。 1...456789101112131415161718...23 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
OOPにおけるジェスチャーの量は原理的に少なくできない。なぜなら、これらのインターフェースはすべて追加のオーバーヘッドであり、ロジックそのものを書くコストを上回ることが多いからである。そして、どんな機能もすでにインターフェイスを持っているにもかかわらず、つまり、本質的に意味のない別の庭を作ることが提案されているのです。
同時に、インターフェースと機能の両方で、コードを変更すると、一方が他方にフックされるため、非常に複雑になり、少なくとも2次関数的にバグの可能性が増え、労働集約的になる...ということです。当たり前といえば当たり前なんですけどね。
OOPにおけるジェスチャーの量は原理的に少なくできない。なぜなら、これらのインターフェースはすべて追加のオーバーヘッドであり、ロジックそのものを書くコストを上回ることが多いからである。そして、どんな関数もすでにインターフェースを持っているにもかかわらず、つまり、本質的に役に立たないヘッジをまた作らなければならないのです。
この場合、インターフェースと機能の両方を変更すると、一方が他方にフックされるため、コードの変更が非常に複雑になり、バグの可能性と労力が少なくとも2次関数的に増加する...当たり前といえば当たり前なんですけどね。
トレーディング、自動売買システム、トレーディング戦略のテストに関するフォーラム
バックヤードでOOPについて語る
fxsaber さん 2018.01.14 11:35
プログラミングそのものは、プロダクションの特殊なケースである。O OPの考え方は、どんなものでも原則的に制作するものです。だから、プログラミングの話をするのは非常に狭量です。OOPは、プログラミングに登場する以前から応用に成功していたのです。
産業の歴史は、コンベア化の次の段階として、オブジェクト指向の「PRODUCTION」に行き着いた。だから、OOプログラミングを語るのは、視野が狭いのです。OOソーイングブーツの話とか。私たちが話しているのは、あらゆる生産物の組織化に対するアルゴリズム的なアプローチであり、非常に特殊なケースとして、ソフトウェアの作成も含まれます。
OOP生産は、従来の組立ラインに対する優位性を競技会で証明しました。今、必要な時に必要なものを作るという、短期的な生産計画があります。そして、長期的なものがあります - あなたが現時点で多くの "余分な "を置くとき、しかし、この基礎は、生産の容易なスケーリングを容易にします。繰り返しになりますが、これはプログラミングの話ではなく、制作における一般的なアプローチの話です。
OOPのアプローチは、現代の権力機関の中にも見られる。
端末は、あなたのコードとの関係では、クラスです。端末のコードを変更する頻度はどのくらいですか？
この例は誤りです。プログラム内のインターフェースの話です...
産業の歴史は、コンベア化の次のステップとして、オブジェクト指向の「PRODUCTION」に行き着いた。
また、OOプログラミングには処理パイプラインがあり、OOPは抽象化の別のレイヤーを導入し、個々のコンベアや生産全体のオーバーヘッドを増加させるだけです。
OOプログラミングにも処理コンベアがあり、OOPは別の抽象化レベルを導入し、個々のコンベアと生産全体のオーバーヘッドを増加させるだけである。
あなたは愚かです、残念ながら。業界の歴史と、その中の一つのステージとして、身の回りのあらゆる物質的（だけでなく）なものに大きな役割を果たしたOOPについて語られます。そして、あなたはプログラミングの特殊な例について話し続けています。
人間形成の歴史に対する無知。直系の子孫の記憶に痕跡を残さない。
業界の歴史と、その中の一つのステージとして、身の回りのあらゆる物質（だけでなく）において大きな役割を果たしてきたOOPについて語られます。
PLOを産業の歴史に引きずり込もうとするあなたの素朴な試みは、面白いけれども、悲しいほど無教養です。
この例は誤りです。プログラム内のインターフェイスの話です...
なぜ「不正解」なのか？
プログラムは、コンピュータ上で動作するすべてのソフトウェアとどのように違うのですか？
結局のところ、どのユーザープログラムでも同じような命令とデータセットが並んでいるのです。なぜ、ソフトウェアのある部分が、確立された交換プロトコルを介する以外に、ソフトウェアの別の部分にアクセスすることができないのですか？
大丈夫、真面目にプログラミングしていれば、遅かれ早かれアクセス権の差別化の必要性に行き着くはずです。
私も、リアルモードからセキュアモードに切り替えたころは、物理的なメモリアドレスにアクセスできないことが嫌でした。DMAコントローラで、保護されたシステム領域から自分の領域にデータをコピーして捻じ込んだこともありました（何をコピーしているのかがわかりにくいので、割愛）。 若い頃は、「どうして直接アクセスできないんだ、権利の侵害に近い」と憤慨していましたが......。また、何かを利用できないようにするプログラムはどうでしょうか？
まあ、経験を積んでいくと、アクセス権の差別化はプログラマー自身にとってもありがたいことで、書いたモジュールのミスを防いでくれることが多いんです。クラスを取って、それを使いたいのに、あるデータにアクセスできない...。憤慨して、どうしてそうなるのか、調べ始めると...。と、おっと...。データには直接アクセスできない「間接経路」があり、直接アクセスすると無効なデータを取得する可能性があるというシステム構成になっているなど、考慮しなければならない点があります。しかし、有効なデータを得ることもできる。すべてはその時点に依存するのだ。そして、そのようなエラーは非常に発見しにくい。
ここで、最も単純な問題は、キャッシュ内のデータへのアクセスである。キャッシュされたデータが必要で、直接アクセスする場合 - 正しいデータが得られるかどうか、確信が持てますか？差別化のない手続き的なアプローチでは、使えるときと使えないとき、データが有効なときとそうでないときを理解しなければならない......。OOPアプローチでは、すべてが非常にシンプルで、キャッシュデータにはアクセスできず、関数を呼び出す だけで、必要なデータを返し、それが無効であれば有効なデータを取得することができるのです。では、このキャッシュを作成してから1年後に使うことを想像してみてください。キャッシュリフレッシュと有効性定義の原則を完全に忘れてしまったとき。OOP-approachでは、気にすることはありません。クラス機能ですべてまかなえます。しかし、関数型アプローチでは、いつ、どのようにキャッシュが更新され、その中のデータがいつ有効で、いつ無効なのかを詳細に覚えておく必要があります。
この例は誤りです。プログラム内のインターフェイスの話です...
端末は、あなたのコードとの関係では、クラスです。あなたには隠されていて、パブリックメソッド（プログラムを実装するための関数）しか提供されていない端末のコードで、何かを変更する必要があることはよくあることでしょう。
+++ )))
端末は、あなたのコードとの関係では、クラスです。端末のコードの中で、自分には隠されていて、プログラムを実装するための関数であるパブリックメソッドだけが提供 されているものを変更する必要があることはよくあることです。
そのようなニーズは定期的に発生します。あくまでも開発者が行うことが望ましい。
簡単な例です。何らかの理由で、開発者はインジケータ・チャートの水平座標グリッドを提供する必要がないと考えた。もちろん、そのための適切な方法も提示されていない）。