過剰なオブジェクト指向脳からの脱却について

一昔前にオブジェクト指向という言葉が全盛期だった時代に、新人や入社２，３年程向けのシステムエンジニアに、コードを小さく分割して共有化していくという手法を推奨した教育があったように思います。

けれども、その手法をゴリゴリに使って作っているシステムが更新期を迎えて、修正作業の為に、その開発にタッチをした事の無いエンジニアがプログラムを確認しようとした時に何が待っているかというと…

自作のオレオレ関数の中に、さらに複数の自作関数が入りまくって、変数一つの流れを追うのも難儀する事になり、地獄の炎上が待っています。

しかも、自作関数の機能のコメントは大雑把で、プログラム内で使われた、一つ一つの変数の役割の説明が無い場合が多いのではと思います。

そして、コードの分割と共有化は保守性が良いという理由ですが、これも大きく間違っています。

実際の修正を行う現場では、自作関数だらけの中でコードの共有化をされていた場合には、特定機能の修正をしたくても、他の共有化された部分にも影響が出てしまう為に　非常な厄介な作りとなります。

その為に、同じコードを、2度以上記述してはいけないという、意味不明なカルトじみた信仰は、WindowsOSなども、まだ存在しない、記憶容量が、KBレベルで工夫をしなければならない数十年前の話だと思います。

現在に、後の修正作業をするエンジニアの事を考えた「まともな作り」をするなら、自作関数の中には自作関数を入れない事が大前提だと思います。

そして、自作関数には、プログラム言語の標準関数のように説明書を丁寧に作成します事と、プログラム内で使った変数は、フラグ用も含めて全て可能なかぎり使用方法を記述した方が良いように思います。

おそらく、PMやPLが、最初に内部設計を作った後に、開発中に発生する、自作関数や変数の説明を定期的に報告してもらい、それを設計書に逐次追加していくような形式が良いように思うのですが・・・

現在のエンジニアの開発現場で、こういう考え方が浸透して、過剰なオブジェクト指向によるコードの分散と共有化という大きな間違いに気が付いてくれるにはどうすれば良いのでしょうか・・・？

No.8 回答者： k-841 回答日時： 2024/05/23 18:53

「自作関数」と「自作じゃない関数」の違いは何？って話ですね。

まぁ「自作関数ガー」とか言っている時点で問題点が手前にあるということを自白しているのだとは思いますけど、それをオブジェクト指向のせいだと転嫁するのは感心しません。

No.7 回答者： tknakamuri 回答日時： 2024/05/20 22:42

>コードを小さく分割して共有化していくという手法

OOPから何でそんな話になるのか解りません。
OOPに限らず、処理のスコープは特に共通/公開用のものを除いて極力狭く
するのが普通。共有化は同じ様な処理が3ヶ所以上現れて初めて検討を始めるもので、当然分かりやすい/使い易い形でかつ良いドキュメントで提供しなければなりません。OOPとは全く無関係な話です。プロジェクトの統制が出来ておらず、実装規約が守られていないということ。あるいはそういう規約さえ未整備ということなんでしょう。

No.6 回答者： naktak 回答日時： 2024/05/20 16:48

APIのクラス設計のプロセスが間違ってるんでしょうね。

オブジェクト指向が悪いのではなく、圧倒的にやり方が誤ってる。
オブジェクト指向の意義は、構造化プログラミングにおいてコードを細分化することではありませんので。

No.5 回答者： lv4u 回答日時： 2024/05/20 09:39

No.2です

前のは、ちょい文章が長かったので、もっと簡単な言い方をします。

オブジェクト指向脳というか、オブジェクト指向のルールがあってもいいと思います。
でも、それだけじゃあなく、それ以前からあって、情報処理試験の問題にも出ていた「複合設計」に出てくるルールを学んで守ることにすればいいかなと思います。

No.4 回答者： だいぬ 回答日時： 2024/05/20 08:20

オブジェクト指向と言うよりもっと基本的な設計部分の話な気がします。

PMやPLが「関数を作る時は適切なコメントを記述すること」や「変数のスコープを広げ過ぎた場合は目的をコメントすること、他の手段を考えること」を明文化しなかったのが間違いで、それを理解できるメンバーが足りなかったんじゃないでしょうか
これってオブジェクト指向の問題なのかなぁ？とか思います。

「じゃあどうすれば良かったのか」と。

オブジェクト指向は設計とリファクタリングを簡単にするためのもので、普通のコピペプログラマにはもしかしたら難易度が高いのかもしれないです。

No.3 回答者： だいぬ 回答日時： 2024/05/20 08:09

もっといい開発手法を提言するとか

色んな意見はあると思うけど、そもそも、学習コストとメンバーの能力が見合ってないせいでそうなってるんじゃないのと思う
コードレビューをうまく入れれば良いし、この質問の内容はもうどっちかって言うとオブジェクト指向の問題じゃあない気がする。

で、そんな依存関係が凄まじくて容易に修正できないってことは開発時に「メンテナンスを諦めて、開発速度を重要視した」と言うだけじゃないかな

当然メンテの際は文句言いながらやるしかない
そこまで大規模なプロジェクトに関わらないのが安牌じゃないかな

No.2 回答者： lv4u 回答日時： 2024/05/20 00:19

＞＞コードを小さく分割して共有化していくという手法を推奨した教育があったように思います。

うん？「コードを小さく分割」ってのは書籍でも目にしましたが、「共有化」ってのは目にしませんでした。

＞＞実際の修正を行う現場では、自作関数だらけの中でコードの共有化をされていた場合には、特定機能の修正をしたくても、他の共有化された部分にも影響が出てしまう為に　非常な厄介な作りとなります。

そういう意味での「コードの共有化」については、初期のオブジェクト指向では、あまり言及されていなかったと思います。
もし、その特定機能の修正をしたら、他の部分にも影響が出るとなれば、オブジェクト指向の失敗、あるいは、オブジェクト以前のモジュール化、関数化の失敗ということでしょうねえ。

＞＞過剰なオブジェクト指向によるコードの分散と共有化という大きな間違いに気が付いてくれるにはどうすれば良いのでしょうか・・・？

過剰なオブジェクト指向というよりも、「まちがったオブジェクト指向」に気づくってことかな？

ちなみに、某社で過去においてオブジェクト指向が大流行した頃に開発されたＣ＋＋アプリにおいて、質問者さんの指摘されるような問題が発生していました。
結局、そのアプリは数億の開発費を費やしましたが、完成直後のレビューで、ＧＵＩに大修正が必要になったのですが、それが無理ってことでボツになったことありましたね。

No.1 回答者： むささび堂 回答日時： 2024/05/20 00:10

オブジェクト指向で開発するいいところは実装を隠蔽してるところ。

あなたの書いてること読むと特定機能の修正は影響範囲が見えないから怖くてできないみたいなことになってるけど、それって全然実装を隠蔽できてないよね。
要するにオブジェクト指向が間違ってるんじゃなくて、あなたの直面している現場が壮大な間違いをやらかしてるだけですね。世の中で起きてるんじゃなくて「おま環」て奴。
どうすればいいかって言うと、オブジェクト指向に対する正しい認識を身につけて実践しましょうってことになります。