オブジェクト指向云々を議論するのは構いませんが、
結局ソースファイルがどこなのか分からなければ
話にならないことを忘れてはならないと思う。

大変なのは、プログラミングそのものより、
自分が手を加えなければいけないのはどの
ソースファイルでどのメソッドなのかということや
どこにディレクトリりを作ってどこに配置をすればいいか
決めることではないのか？

継承やポリモーフィズム、オーバーライド
抽象クラス、インタフェースとか使いこなすのは構わないが
ソースがどこにあるか余計わからなくなるようでは
後から参加する人が困ります。

また、ディレクトリ構造にはソースファイルが
だけがあるわけではない。
HTMLや画像や音声や設定ファイルや
JSON,XMLファイル、アプリ特有の特殊なバイナリ
だってあるんだ
これらをどう配置すればいいかなんて誰も教えてくれない
じゃないですか。

もっと最悪なのは
外部ソースをインクルードする文
そのものが変数化されてたり
関数型プログラミングやリフレクションにかぶれて
関数とかクラスが変数化されていることにより
実行されているソースそのものが
ソース読んだだけじゃ追いにくくなってたり

フレームワークの特殊な命名規約や
特殊ルール知ってないと、どこに処理が飛んでるのか
ソースを追えなくなったりすることが多すぎる。

新人とかに実装投げても、3時間経ってもまだ
ソース探してんだよ。
状況を聞くと「こりゃ初見じゃ無理だ。」って
思わざるを得ないことが多い。
俺が全部ソース探し手伝わなきゃならんのか？

でも親子クラスの配置とか
抽象クラスやインタフェースと
実装クラスの配置まで考えて言うほど厳密に
ディレクトリ設計するか？

あと共通してどこからでも呼び出される
モジュールや関数とか

HTMLの共通外枠テンプレとか共通組み込み画面部品とか
CSSやJavaScriptの共通読み込みファイルとか
何だかんだグダグダになってカオス化しやすいイメージ
特に画面の部品はDIYを捨てて共通化せずに
画面とファイルが1対1の関係で使い捨てた方が絶対いい
コピペだってDIYだろ
画面だけは無闇に動的変動要素だらけにせずに直書きの方がメンテしやすい
バックエンドは共通化すべきだが

ディレクトリ構造ってのはアプリケーションアーキテクチャの設計を反映したものなんよね

開発者にとってはディレクトリ構造がコードレベルでアーキテクチャを理解するための第一歩

責務は能力と権限をセットにしたもの

テストとテストでないプログラムは機能も実行タイミングもアクターも違うので
分けていいと思うけど、パッケージプライベートのクラスをテストするために
クラスパスを同じにすることはあるよねー

形式と意味と意図
これらを区別して考えられないやつはクソプログラマー
クソプログラマーほど意図ではなく形式に意識が向かう

なぜか？

日本語には意志動詞と無意志動詞という区別があってだな
意志動詞はその主体が意志を持って動作を行っている様を表現したいときにのみ使うもの

オブジェクト指向と擬人化思考の相性がいい理由の一つ