OOPと手続き型プログラミングの比較 - ページ 8

 
Dmitry Fedoseev:

すべてのオープンオーダーをすべてのパラメータとともに配列にロードするのは合理的なアプローチではないかもしれません。


おそらく、私のコードで利益とストップロスの 2つのパラメータが必要な場合、ループを2回実行するのは高すぎます。

これは世界共通のコードなので、不要なものを削って最終的なスピードを上げる......。

 
Vladimir Pastushak:

シンプリファイ

だから私はOOPに耐えられないんです。何も理解することができないのです。解説がないんです。最後に求められるものは何でしょうか?
 
Реter Konow:
だから私はOOPに耐えられないんです。何も理解することができないのです。解説がないんです。最終的に何が求められるか?

さっそく勉強してみたらどうだろう?

 
Реter Konow:
だから、私はOOPが嫌いなんです。何も理解することができないのです。コメントはありません。最終的に何が求められるか?

それが、わかっていないのに、すべての命令を配列構造で持っていて、どこでも簡単に呼び出せるということです。しかも、ヘビーループは1回しか実行しないし...。

 
Dmitry Fedoseev:

さっそく勉強してみたらどうだろう?

ループ内で配列を 関数値で埋めます。問題は、なぜクラスシェルが必要なのか、ということです。機能でなんとかなる。
 
Реter Konow:
ループ内の関数の値で配列を埋めます。問題は、なぜクラスシェルが必要なのか、ということです。関数でできる。

関数呼び出しが少なければ少ないほど、コードは高速になります。

 
Реter Konow:
ループ内で配列に 関数の値を入れる。問題は、なぜクラスシェルが必要なのか、ということです。関数でも可能です。

配列を積み上げたり、個別にサイズを変更したりする必要がなく、非常に便利な構造です。この例は、OOPの利点を示すものではなく、誰もが個人的に快適な方法でやっているというだけのことです。

 
Vladimir Pastushak:

それが、わかっていないのに、すべての命令を配列構造で持っていて、どこでも簡単に呼び出せるということです。同時に、重いループを一度だけ走らせる...。

理解できないのは、自分のコードじゃないし、一部に過ぎないからだと理解しています。でも、あなたも理解していないようですね。私が間違っているのでしょうか?
 
Dmitry Fedoseev:

紳士的な論客の皆さん、こう言いましょう、OOPを理解していない、知らない、ならば、手続き型プログラミング対OOPではなく、関数へのポインタを持つ手続き型プログラミング対関数へのポインタを持たない手続き型プログラミングで議論しましょうよ。

いいえ、あなたの例はとても良いものです。

手続き型プログラミングのことではありません。

プログラムの品質には、コードの明確さというもっと重要な基準があります。

あなたの出した解答はひどいものです。どのような関数が意味を持って呼び出されているのかがまったくわかりません。それぞれのコールに対して、通常のスイッチとコメントを書くのです。これが正しいコードです。

あなたの例から、私はOOPは有害であると結論付けます。

 
Vladimir Pastushak:

関数呼び出しが少なければ少ないほど、コードは高速になります。

だから、私は大きな汎用的なコードのブロックを作るのが好きなんです。