DBのテーブル数や列数が少なくて
テーブル設計が洗練されているならオブジェクト指向っていいんだろうね。
でも現実のシステム考えるとアホみたいにテーブルの数が多くて
アホみたいに列の数が多くて、整理もされていないわけじゃん。
そしてアホみたいに文言の定数定義とかも多い。
そうすると、階層構造作ってレイヤの数を増やして
結果的1つの機能を達成するのに作るファイルの数が増えるほど、
それらのアホみたいに多くて長い列名をレイヤの数だけ書きまくる
みたいな苦行が待っているわけじゃん。
少しでも項目名の変更があったらそれらのファイル部書き換えたり
クラス名に変更がありでもしたらファイル名やフォルダ名とか、
テーブル名、import文とか全部書き換えになるわけじゃん。
それにオブジェクト指向でどう頑張っても最終的に値を
埋め込む画面が汚くなるのは避けることができない。
そうするとオブジェクト指向設計で無理にファイルを分けて
構造化するリスクってやばいと思う。
そうなると少ないファイルオブジェクト指向クソ喰らえみたいな勢いで
構造化プログラミングだけでゴリッと書くほうが早いと思うんだよね。
命名規則もいちいち気を使わないで勢いで書くんだよ。
ファイルの中関数定義だらけになるが、
その中で似たような処理の関数見つけてきて、複製して、
今必要な処理ができるように改変して新たな関数を作る。これで十分だ。
1ファイルの中で完結しているんだから不具合は波及しない。
ファイルをまたいでimportして無理にファイルの昨日使う必要性なんて
どこにも有りはしないだろ。ファイルの頭からimportやextend inplementだらけ
とか吐き気がするよ。
オブジェクト指向ってファイル間の関連性追ったり、
ファイル構造を含んだデバッグの苦痛は無視してんのか？って思う。