手続き型コードにできなくて、OOPコードにできることは何ですか？ - ページ 3 12345 新しいコメント James Cater 2016.05.24 13:31 #21 小規模なプロジェクトであれば、どんな問題も手続き的なコードに分解できることを示すことができます。しかし、数百万行のコードベースに、100人以上の開発者、数人のビジネスアナリスト、アーキテクトが、同時に「モデル」に修正を加えたいと考えた場合、事態はかなり困難になってきます。このような状況では、「ビジネス」モデルは一般的にUMLのような設計ツールで定義され、チーム全体がアクセスできるようになります。ビジネスモデルだけでも5000以上のクラスが存在します。このビジネスモデルから、オブジェクトモデル、SQLインターフェース、ネットワーク層のクラスを「生成」するツールがあり、ベースラインのクラス数は15,000クラスにもなります。この議論では、手続き型とオブジェクト指向の議論を、1960/1970年代以降に手続き型に追加された3つの「拡張」に分解してみたいと思います。1) 「オブジェクトベース」 オブジェクトとコードがカプセル化され、ビヘイビアを持つことができる高度な「構造」を作ることです。 2) 「クラスベース」オブジェクトを互いに継承し、階層的に配置できる。3) 「オブジェクト指向」：ユーザーがクラス階層の中で「ポリモーフィック」な振る舞い（仮想メソッドやインターフェース）を定義することができる。例えば、80年代、90年代のほとんどのGUIツールキットはc言語で作成され、これらの機能を備えていました。では、100人以上の開発者が参加する数百万行のプロジェクトを、3つのOOP機能を使わずに実装できるでしょうか？私の個人的な意見としては、1)と2)を使わずに大規模なプロジェクトを実現することは事実上不可能だと思います。なぜなら、「クラスベース」のシステムがなければ、現実世界のデータ 構造と動作をきれいかつ簡潔な方法でコードにマッピングすることは非常に難しいからです。さらに言えば、プロジェクトの規模が大きくなると、「これはcで実装できる」と思っていたものが、構造が複雑なメソッドの羅列になり、メンテナンスが大変になります。1)と2)のみを実現する言語では、完全なOOP言語とは言えません。そこで、「ポリモーフィック（仮想）メソッド」が本当に必要なのかどうかを考える必要があります。これは、ポリモーフィズムが必ずしも問題を解決するための正しいツールではなく、設計を複雑にしすぎる可能性があるため、「たぶん」「ときどき」という感じになっています。例えば、オブジェクトストアやSQLデータベースにマッピングされるデータ構造をモデル化するときに、仮想的な振る舞いを追加するとデータマッピングが難しくなります。しかし、拡張可能なツールキットやAPIを定義するときに、「インターフェース」または「仮想メソッド」を持つベースクラスを使用することは非常に貴重です。全体として、私は、適切な文脈で控えめに使用されるポリモーフィズムの大ファンです。私は、数百万行の「C」コードベースと数百万行のC++/Java/C#コードベースで働いてきましたが、ほとんどの「C」コードベースは5年後に「メンテナンスモード」になってしまいます。なぜなら、開発者はコードがあまりにも脆弱で、変更すると何ヶ月もかかる再開発とテストがしばしば発生するため、アーキテクチャを変えるのを怖がるのです。一般に、オブジェクト指向のプロジェクトは、修正やリファクタリングに対してより強いです。 James Cater 2016.05.24 13:50 #22 Alain Verleyen: 「if...then...else...」文がその役割を担っているはずです。if...then...else は、「仮想」メソッドをコーディングすることはできません。C言語」には「ポリモーフィズム」の実装がいくつかありますが、そのほとんどは、必要なマッピングを保持するために関数 ポインタのベクトルを使用しています。さらに言えば、この「関数ポインタのベクトル」は、「階層」の中でモデル化したい「型」ごとに定義する必要がある。もちろん、「C」は階層を直接サポートしていないので、その問題も解決しなければなりません。もし、本当に「C」で実装された「仮想」メソッドという虫袋に入りたいなら、すべてのLinuxディストリビューションで自由に利用できるX Windowsツールキットを掘り出すことができます。Windowsはもちろん少し違っていて、整数のメッセージIDを持つ拡張可能な構造体を使います。 つまり、「ポリモーフィック」な動作はIDのswitchステートメントで実装されているのです。(おそらく最も汚い方法ですが、これで実現できます) James Cater 2016.05.24 14:11 #23 Alain Verleyen:Windowsオペレーティングシステムが優れたGUIを提供していることに同意しますか？私の知る限り、それはCで書かれています。OOPではなく手続き型言語です。もし、複雑なプログラムがOOPでなければ作れないと思うなら、あなたは間違っています。むしろ、なぜOOPでコーディングした方が良いのかを説明すべきです。Windowsのカーネルは"C "言語ですが、カーネルはWindowsのコードベースのほんの一部に過ぎず、上位のコードベースの多くは、複数の言語をサポートする "C "スタイルの外部インターフェースを備えたC++で実装されています。レガシーなWindowsのGUIコンポーネントでさえ、独自の手巻き「ポリモーフィック動作」を実装しており、事実上「C」で実装された「OOP」になっています。たとえば、GUIコントロールから「ハンドル」を受け取るとき、あなたはポリモーフィックな動作が利用できる拡張可能な「C」構造を得ているのであり、これは「C」構文の醜いセットで包まれただけのOOPです。Windows は C 言語で書かれているから OOP ではないというのは、まったく正確ではありません。 James Cater 2016.05.24 14:42 #24 Alain Verleyen:私は、あなたが間違っていることを証明するために、手続き型言語でGUIを構築するつもりはありません。しかし、私は間違いなくそうすることができます。ところで、OOPでは、読めないコードやずっと遅いコードを書くことも簡単です。ご存知のように、Metaquotes標準ライブラ リはその良い証拠です。OOPが手続き型コードよりずっと遅いというのは完全な神話です。多くのOOPプロジェクトが遅いのは、その設計が悪いからです。仮想関数呼び出しのオーバーヘッドは、特に最近のオンチップメモリフェッチアーキテクチャでは、ルックアップと並列実行が可能なので、予想よりはるかに小さいのです。https://hbfs.wordpress.com/2008/12/30/the-true-cost-of-calls/上記のリンクからの引用：「しかし、呼び出しのコストは、どのようなものであれ、その引数の評価によって支配されています。間接的な呼び出しは、CスタイルであろうとC++の仮想メソッドであろうと、本質的に安価で あることを見てきました。仮想メソッドの呼び出しは、構造体メンバを使った間接呼び出し（something->function(arg1,arg2)）よりもコストがかからないので、仮想関数が信じられないほど遅いと見なすのは単なる誤情報である。"JavaはC++よりずっと遅いかもしれません。なぜなら、カプセル化されたデータのすべてがヒープベースのクラスでなければならないので、オブジェクトの再参照が多くなってしまうからです。しかし、Javaでも、ループや基本的な数学演算ではCとまったく同じ速度になります。CとC#を比較した場合、CとC#で有意に速いコードを書くのは、OOPの機能をいくつか含めても、本当に難しいことなのです。Metaquotes標準ライブラリが遅いとしたら、それは90％ライブラリ機能の設計によるもので、使用されているOOP機能とはほとんど関係がないでしょう。(比較として、C++の標準テンプレートライブラリは、これまでに書かれたどのCプロジェクトよりも95%も性能が優れています) Alain Verleyen 2016.05.24 15:42 #25 James Cater:...素晴らしいご投稿をありがとうございました。 James Cater 2016.05.24 17:19 #26 Alain Verleyen:素晴らしい貢献をありがとうございました。 ありがとうございます、そして私はあなたを非難しているわけではありません、ただあなただけが手続き上の議論を支持しているだけです :) Alain Verleyen 2016.05.24 18:13 #27 James Cater: ありがとうございます、そして私はあなたを非難しているわけではありません、ただあなただけが手続き上の議論を支持しているだけです :)心配しないでください、私は "司会者 "としての役割を果たさなければなりません。 Donald Gibson 2016.05.24 23:41 #28 もちろん、あなた方が話していることが何であれ、いくつかの例を見ることができたらいいと思います。しかし、私は視覚的なハンズオンタイプの学生なので、例を掲載してください。私は、mql4の学習を続けるか、mql5に切り替えるか、それとも他のプラットフォームにするか、迷っているところです。このスレッドを開始するためのアランに感謝します。このフォーラムは本当にこれを必要とします。 Doerk Hilger 2016.05.25 00:40 #29 プロフェッショナルな人が「証拠」としてcompexライブラリを投稿しているとでも思っているのでしょうか？）私はここの市場で売ることができない何か準備ができているリンクをあなたに投稿することができますが、私がそうするならば、Alainは私を蹴るつもりです;)私のプロフィールを見て、壁の写真を見て、アイデアを得るか、私にPMを送ることができます。他のプラットフォーム？これほど強力なコンパイラを持つプラットフォームは他にはないでしょう。全くです。James Cater - コメントありがとうございました。 Alain Verleyen 2016.05.25 08:17 #30 Doerk Hilger:プロフェッショナルな人が「証拠」としてcompexライブラリを投稿しているとでも思っているのでしょうか？）私はここの市場で売ることができない何か準備ができているリンクをあなたに投稿することができますが、私がそれをしたらAlainは私を蹴るつもりです;)私のプロフィールを見て、壁の写真を見て、アイデアを得るか、私にPMを送ることができます。他のプラットフォーム？これほど強力なコンパイラを持つプラットフォームは他にはないでしょう。全くです。James Cater - コメントありがとうございました。 Dirkの指摘は的外れです。専門家でない人たちは、シンプルでわかりやすいコード例を求めていますし、実際、このトピックで私が目指したのもそれでした。しかし、それは専門家の理解を完全に超えているようです。 12345 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
小規模なプロジェクトであれば、どんな問題も手続き的なコードに分解できることを示すことができます。しかし、数百万行のコードベースに、100人以上の開発者、数人のビジネスアナリスト、アーキテクトが、同時に「モデル」に修正を加えたいと考えた場合、事態はかなり困難になってきます。このような状況では、「ビジネス」モデルは一般的にUMLのような設計ツールで定義され、チーム全体がアクセスできるようになります。
ビジネスモデルだけでも5000以上のクラスが存在します。このビジネスモデルから、オブジェクトモデル、SQLインターフェース、ネットワーク層のクラスを「生成」するツールがあり、ベースラインのクラス数は15,000クラスにもなります。
この議論では、手続き型とオブジェクト指向の議論を、1960/1970年代以降に手続き型に追加された3つの「拡張」に分解してみたいと思います。
1) 「オブジェクトベース」 オブジェクトとコードがカプセル化され、ビヘイビアを持つことができる高度な「構造」を作ることです。
2) 「クラスベース」オブジェクトを互いに継承し、階層的に配置できる。
3) 「オブジェクト指向」：ユーザーがクラス階層の中で「ポリモーフィック」な振る舞い（仮想メソッドやインターフェース）を定義することができる。
例えば、80年代、90年代のほとんどのGUIツールキットはc言語で作成され、これらの機能を備えていました。
では、100人以上の開発者が参加する数百万行のプロジェクトを、3つのOOP機能を使わずに実装できるでしょうか？
私の個人的な意見としては、1)と2)を使わずに大規模なプロジェクトを実現することは事実上不可能だと思います。なぜなら、「クラスベース」のシステムがなければ、現実世界のデータ 構造と動作をきれいかつ簡潔な方法でコードにマッピングすることは非常に難しいからです。さらに言えば、プロジェクトの規模が大きくなると、「これはcで実装できる」と思っていたものが、構造が複雑なメソッドの羅列になり、メンテナンスが大変になります。
1)と2)のみを実現する言語では、完全なOOP言語とは言えません。そこで、「ポリモーフィック（仮想）メソッド」が本当に必要なのかどうかを考える必要があります。これは、ポリモーフィズムが必ずしも問題を解決するための正しいツールではなく、設計を複雑にしすぎる可能性があるため、「たぶん」「ときどき」という感じになっています。例えば、オブジェクトストアやSQLデータベースにマッピングされるデータ構造をモデル化するときに、仮想的な振る舞いを追加するとデータマッピングが難しくなります。しかし、拡張可能なツールキットやAPIを定義するときに、「インターフェース」または「仮想メソッド」を持つベースクラスを使用することは非常に貴重です。全体として、私は、適切な文脈で控えめに使用されるポリモーフィズムの大ファンです。
私は、数百万行の「C」コードベースと数百万行のC++/Java/C#コードベースで働いてきましたが、ほとんどの「C」コードベースは5年後に「メンテナンスモード」になってしまいます。なぜなら、開発者はコードがあまりにも脆弱で、変更すると何ヶ月もかかる再開発とテストがしばしば発生するため、アーキテクチャを変えるのを怖がるのです。一般に、オブジェクト指向のプロジェクトは、修正やリファクタリングに対してより強いです。
「if...then...else...」文がその役割を担っているはずです。
if...then...else は、「仮想」メソッドをコーディングすることはできません。
C言語」には「ポリモーフィズム」の実装がいくつかありますが、そのほとんどは、必要なマッピングを保持するために関数 ポインタのベクトルを使用しています。さらに言えば、この「関数ポインタのベクトル」は、「階層」の中でモデル化したい「型」ごとに定義する必要がある。もちろん、「C」は階層を直接サポートしていないので、その問題も解決しなければなりません。
もし、本当に「C」で実装された「仮想」メソッドという虫袋に入りたいなら、すべてのLinuxディストリビューションで自由に利用できるX Windowsツールキットを掘り出すことができます。
Windowsはもちろん少し違っていて、整数のメッセージIDを持つ拡張可能な構造体を使います。 つまり、「ポリモーフィック」な動作はIDのswitchステートメントで実装されているのです。(おそらく最も汚い方法ですが、これで実現できます)
Windowsオペレーティングシステムが優れたGUIを提供していることに同意しますか？私の知る限り、それはCで書かれています。OOPではなく手続き型言語です。
もし、複雑なプログラムがOOPでなければ作れないと思うなら、あなたは間違っています。むしろ、なぜOOPでコーディングした方が良いのかを説明すべきです。
Windowsのカーネルは"C "言語ですが、カーネルはWindowsのコードベースのほんの一部に過ぎず、上位のコードベースの多くは、複数の言語をサポートする "C "スタイルの外部インターフェースを備えたC++で実装されています。
レガシーなWindowsのGUIコンポーネントでさえ、独自の手巻き「ポリモーフィック動作」を実装しており、事実上「C」で実装された「OOP」になっています。たとえば、GUIコントロールから「ハンドル」を受け取るとき、あなたはポリモーフィックな動作が利用できる拡張可能な「C」構造を得ているのであり、これは「C」構文の醜いセットで包まれただけのOOPです。
Windows は C 言語で書かれているから OOP ではないというのは、まったく正確ではありません。
私は、あなたが間違っていることを証明するために、手続き型言語でGUIを構築するつもりはありません。しかし、私は間違いなくそうすることができます。
ところで、OOPでは、読めないコードやずっと遅いコードを書くことも簡単です。ご存知のように、Metaquotes標準ライブラ リはその良い証拠です。
OOPが手続き型コードよりずっと遅いというのは完全な神話です。多くのOOPプロジェクトが遅いのは、その設計が悪いからです。仮想関数呼び出しのオーバーヘッドは、特に最近のオンチップメモリフェッチアーキテクチャでは、ルックアップと並列実行が可能なので、予想よりはるかに小さいのです。
https://hbfs.wordpress.com/2008/12/30/the-true-cost-of-calls/
上記のリンクからの引用：「しかし、呼び出しのコストは、どのようなものであれ、その引数の評価によって支配されています。間接的な呼び出しは、CスタイルであろうとC++の仮想メソッドであろうと、本質的に安価で あることを見てきました。仮想メソッドの呼び出しは、構造体メンバを使った間接呼び出し（something->function(arg1,arg2)）よりもコストがかからないので、仮想関数が信じられないほど遅いと見なすのは単なる誤情報である。"
JavaはC++よりずっと遅いかもしれません。なぜなら、カプセル化されたデータのすべてがヒープベースのクラスでなければならないので、オブジェクトの再参照が多くなってしまうからです。しかし、Javaでも、ループや基本的な数学演算ではCとまったく同じ速度になります。
CとC#を比較した場合、CとC#で有意に速いコードを書くのは、OOPの機能をいくつか含めても、本当に難しいことなのです。
Metaquotes標準ライブラリが遅いとしたら、それは90％ライブラリ機能の設計によるもので、使用されているOOP機能とはほとんど関係がないでしょう。
(比較として、C++の標準テンプレートライブラリは、これまでに書かれたどのCプロジェクトよりも95%も性能が優れています)
...
素晴らしいご投稿をありがとうございました。
素晴らしい貢献をありがとうございました。
ありがとうございます、そして私はあなたを非難しているわけではありません、ただあなただけが手続き上の議論を支持しているだけです :)
心配しないでください、私は "司会者 "としての役割を果たさなければなりません。
もちろん、あなた方が話していることが何であれ、いくつかの例を見ることができたらいいと思います。しかし、私は視覚的なハンズオンタイプの学生なので、例を掲載してください。
私は、mql4の学習を続けるか、mql5に切り替えるか、それとも他のプラットフォームにするか、迷っているところです。
このスレッドを開始するためのアランに感謝します。このフォーラムは本当にこれを必要とします。
プロフェッショナルな人が「証拠」としてcompexライブラリを投稿しているとでも思っているのでしょうか？）私はここの市場で売ることができない何か準備ができているリンクをあなたに投稿することができますが、私がそうするならば、Alainは私を蹴るつもりです;)私のプロフィールを見て、壁の写真を見て、アイデアを得るか、私にPMを送ることができます。
他のプラットフォーム？これほど強力なコンパイラを持つプラットフォームは他にはないでしょう。全くです。
James Cater - コメントありがとうございました。
プロフェッショナルな人が「証拠」としてcompexライブラリを投稿しているとでも思っているのでしょうか？）私はここの市場で売ることができない何か準備ができているリンクをあなたに投稿することができますが、私がそれをしたらAlainは私を蹴るつもりです;)私のプロフィールを見て、壁の写真を見て、アイデアを得るか、私にPMを送ることができます。
他のプラットフォーム？これほど強力なコンパイラを持つプラットフォームは他にはないでしょう。全くです。
James Cater - コメントありがとうございました。