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

[Vladimir Pastushak]

Реter Konow:
なぜ理解できないのか、それは私のコードではない、しかも一部に過ぎないということは理解できました。でも、あなたも理解していないようですね。私が間違っているのでしょうか？

ポインターは使いません...。

以前は、私もあなたと同じように、関数だけで作業していました。しかし、時間とともに、関数を何らかの方法で保存しなければならなくなり、それから関数を検索しなければならなくなり、それぞれの関数が独自の追加動作をするようになりました。

現在、すべてをクラスに再構築し、Orderクラスを呼び出すと、必要なものすべてと、利用可能な関数やメソッドのリストが表示されます...。

[Alexandr Andreev]

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

OOPなしで良いGUIを作る作者も信じられん

コードの行数を節約するのか!

[Dmitry Fedoseev]

СанСаныч Фоменко:

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

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

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

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

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

また、1つしか使われないことが事前に分かっているのに、なぜ100種類ものバリエーションで切り替えるのでしょうか？

3行のコードに比べ、100個のバリアントスイッチのスプールに何の意味があるのでしょうか？

合理的に、最適に（完璧にさえ）できることを、複雑で、大規模で、動きの遅いものにするのはおかしい。

OOPは使い方を間違えると有害なだけです。

この コメントへの対応をお願いします。

[Dmitry Fedoseev]

Реter Konow:
だから、私は普遍的な大きなコードのブロックを作るのが好きなんです。

何が普遍的なのか？

[СанСаныч Фоменко]

Dmitry Fedoseev:

1台しか使わないことがあらかじめ分かっているのに、なぜ100台ものバリエーションスイッチが必要なのでしょうか？

3行のコードと比較して、100バリエーションあるスイッチのわかりやすさはどうでしょうか？

合理的に、最適に（完璧にさえ）できるような、複雑で、大きく、遅いものを作るのは、正しいアプローチではありません。

この コメントへの対応をお願いします。

ネタバレではありません。プログラムの機能とプログラムのテキストを組み合わせたドキュメントです。これは最も重要なことで、何が単独で機能するかということではない

[Реter Konow]

Vladimir Pastushak:

ポインターは使いません...。

以前は、私もあなたと同じように、関数だけで作業していました。しかし、時間とともに、関数を何らかの方法で保存しなければならなくなり、それから関数を検索しなければならなくなり、それぞれの関数が独自の追加動作をするようになりました。

現在では、すべてをクラスに再構築し、Orderクラスを呼び出すと、必要なものすべてと利用可能な関数やメソッドのリストが表示されます...。

その方が都合がいいのであれば、何も反対はしません。私の豊富なプログラミング経験から言うと、普遍化と圧縮を適用すれば、どんな課題もOOPなしでも同じように解決できるのです。これは、偉大な実践によって確認された経験です。おそらく、どちらかのアプローチが、私たち個人の考え方の特殊性に関係しているのでしょう。これが、私がお伝えしたい最大のポイントです。

[Dmitry Fedoseev]

СанСаныч Фоменко:

これはネタバレではなく、プログラムの機能をプログラムのテキストと組み合わせたドキュメントです。これは最も重要なことで、何が単独で機能するかということではない

スロッピングもバラストも。フライは別々、カツも別々にしてください。ドキュメンテーションは重要ですが、プログラムの運用を妨げてはいけません。

[Реter Konow]

Dmitry Fedoseev:

何が普遍的なのか？

例えば、コントロールを作成してグラフィカルなオブジェクトを相対的に配置するブロックが必要です。同時に、同じブロックがオブジェクトの現象を制御する、つまり、あるオブジェクトを隠し、別のオブジェクトを表示することもできます。また、スクロールバーの寸法や ウィンドウ全体の寸法を計算することもできます。また、スクロールバー内のスライダーの動きも計算します。これは、オブジェクト関係の普遍的なブロックです。

あるいは、ウィンドウハンドルを握ったときのウィンドウの大きさを制御するブロック。あるいは、コントロールの状態を制御するブロック。あるいは、カーソルがどの要素にあるかを計算し、同時に多くのグローバルパラメータにフォーカスを当てるブロック......。

[Dmitry Fedoseev]

Реter Konow:
例えば、コントロールを作成してグラフィカルなオブジェクトを相対的に配置するブロックが必要です。同時に、同じブロックがオブジェクトの現象を制御する、つまり、あるオブジェクトを隠し、別のオブジェクトを表示することもできます。また、スクロールバーの寸法やウィンドウ全体の寸法を計算することもできます。また、スクロールバー内のスライダーの動きも計算されます。ユニバーサル・オブジェクト・リレーション・ブロックです。

しかし、これはifとswitchで実装されていますね。

[Реter Konow]

Dmitry Fedoseev:

しかし、これはifとswitchで実装されていますね。

そう、このブロックにはその両方が備わっているのです。でも、信じてください。彼らは最大まで圧縮され、幅広い問題を解決してくれるから、汎用性があるのです。