🏠 ホーム
フロントエンド
PHP
Go言語
プログラミングの理解
プログラマーへの道
Google API

オブジェクト指向って古い。もうやめませんか? 自分がフレームワークを作る側でもないのに作りたがる衝動

  プログラミング >     プログラミングの理解 >  

#3 オブジェクト指向って古い。もうやめませんか? 自分がフレームワークを作る側でもないのに作りたがる衝動【主張】 - YouTube


オブジェクト指向ってプログラミングの基本かと思いますが、どうしても、疑問を感じながらプログラミングしていました。

フレームワークを作る側であればセッションとかCSRFなどは使い回す必要があるため、共通関数にするメリットはおおいにありますが、フレームワークを使う側で共通関数を作るメリットはないかと思います。


というのは論理的に考えれば共通クラスを作れば作るほど属人化してしまい、ゴッドオブジェクトのような惨事になってしまうので何1つメリットないんじゃないかと思っています。


まるでオブジェクト指向を逆らったかのうようなに作られた言語があります。

それがGo言語


Go言語はJava,C++を使っていたGoogleエンジニアがJava,C++の弱点を補って、いいところだけを取り入れて作った言語だそうです。


これらのURLから

Frequently Asked Questions (FAQ) - The Go Programming Language

https://en.wikipedia.org/wiki/Orthogonality_(programming)Orthogonality

(直交性)を提唱していてできる限り互いのクラスの依存性をなくす書き方を推奨しています。


classや継承、例外処理がない部分がオブジェクト指向ではない部分です。


ずっと自分だけがオブジェクト指向に疑問を抱いていたと思ったのですが、あのGoogleエンジニア達が同じような事を考えていると自信がついたので、なぜオブジェクト指向がダメなのかをコードを書きながら説明していきます。


ケースとしては、セキュリティの設定のため全てのリクエストに対してセキュリティの処理をしないといけないという要望を受けます。


そうなると一つ一つのコントローラにいちいち同じセキュリテイ処理をする事は面倒なので、すべてのコントローラの親であるBaseControllerを改修してセキュリティーの機能をつけます。


次の要件は全てのページで画像などのSNSの情報を表示させたいという要望がありました。


その次の要件では、全てではなく、ログインしていないページはそもそもSNSの情報を表示できないので、ログインしていないページは除外するという要望になります。


そういった要件、設計が変わっていくけども、親クラスでの改修がエスカレートしていき、その親クラスでどのページへのリクエストか、もしくはログインしているのかしていないのかで、条件分岐が必要になってきます。


結果BaseControllerがゴッドオブジェクトになってしまいます。

全てのページの改修の時にこのBaseControllerを作成したエンジニアにお伺いをたてないといけない事になります。


そうなってしまっては、全然違う別ページ、別機能での改修でもBaseControllerを変更する時はその関数が使われている箇所があるのかないのかを毎回検索してチェックする必要が出て来て、BaseControllerが使われているページ全てテストし直す必要があります。


さらに、どの機能をどこの所属させるかの判断を迷わないでしょうか?これはモデル?ヘルパー?ライブラリ?あと、どれくらいの大きな機能をどう分割して、返り値で渡すのかクラス変数で共通化するのか。

コンストラクタで共通機能を実装するのか、継承元で実装するのかクラスが持つ関数はいくつまでにするのかなど、判断しないといけないところがありすぎかと思います。

個人に任せれば、属人的になるし、方針を決めれば決める時間が費やされるのとそれに従うスピードが落ちてしまいます。


オブジェクト指向では依存関係が発生しやすいので、どこかのクラスを改修しないといけないとなった場合はその関数が使われているファイルを全検索して確認しないと想定外の部分で障害になったりします。

そして、検索された箇所全てを考慮して改修する必要があります。

 

それだけでゾッとしないでしょうか?


そうなるとできる限り依存しない設計、できる限り小さい関数でクラスを分けたくなります。

それはそれでそうなると、3行程度の機能のためにわざわざ関数作成して、呼びたしもとが1つのクラスのみになります。

であれば初めから、直接ベタ書きにすればいいんじゃないかと思います。


書くエンジニアからすれば、できるだけDRY (Don't Repeat Yourself)に書ければコード量も少ないので、綺麗に見えるかも知れませんが、新しく入ってきたエンジニアからすればとっつきにくかったりもします。

 

要件変更があった時は互いのクラスが密結合しているとどうしても影響範囲が大きくなり変更しにくくなります。


なので、DDD、ポリモーフィズム、ファットモデル(コントローラ)などの考え方は全て百害あって一利なしです。

Goでベタ書き(そうせざるを得ない)すれば誰が書いても同じようなソースコードになるので、保守性が優れているので、その観点からもおすすめです。

 

バックエンド用語のクイズ集
https://programming.quigen.info/category/2/99/

登録日:

更新日:

by

コメント         tweetでコメント