オブジェクト指向のディレクトリ構造の調査と設計
■ このスレッドは過去ログ倉庫に格納されています
オブジェクト指向云々を議論するのは構いませんが、
結局ソースファイルがどこなのか分からなければ
話にならないことを忘れてはならないと思う。
大変なのは、プログラミングそのものより、
自分が手を加えなければいけないのはどの
ソースファイルでどのメソッドなのかということや
どこにディレクトリりを作ってどこに配置をすればいいか
決めることではないのか?
継承やポリモーフィズム、オーバーライド
抽象クラス、インタフェースとか使いこなすのは構わないが
ソースがどこにあるか余計わからなくなるようでは
後から参加する人が困ります。
また、ディレクトリ構造にはソースファイルが
だけがあるわけではない。
HTMLや画像や音声や設定ファイルや
JSON,XMLファイル、アプリ特有の特殊なバイナリ
だってあるんだ
これらをどう配置すればいいかなんて誰も教えてくれない
じゃないですか。 もっと最悪なのは
外部ソースをインクルードする文
そのものが変数化されてたり
関数型プログラミングやリフレクションにかぶれて
関数とかクラスが変数化されていることにより
実行されているソースそのものが
ソース読んだだけじゃ追いにくくなってたり
フレームワークの特殊な命名規約や
特殊ルール知ってないと、どこに処理が飛んでるのか
ソースを追えなくなったりすることが多すぎる。
新人とかに実装投げても、3時間経ってもまだ
ソース探してんだよ。
状況を聞くと「こりゃ初見じゃ無理だ。」って
思わざるを得ないことが多い。
俺が全部ソース探し手伝わなきゃならんのか? 意訳 ディレクトリ構造=クラス構造のJavaは先見の明があったな 初心者は何をやるにしたってつまづくんだから教えてやれよで終わり ディレクトリ構造をドキュメントに落としてないとこなんてあるのか
新しく参加した開発者に最初に説明する内容でしょ でも親子クラスの配置とか
抽象クラスやインタフェースと
実装クラスの配置まで考えて言うほど厳密に
ディレクトリ設計するか?
あと共通してどこからでも呼び出される
モジュールや関数とか
HTMLの共通外枠テンプレとか共通組み込み画面部品とか
CSSやJavaScriptの共通読み込みファイルとか
何だかんだグダグダになってカオス化しやすいイメージ
特に画面の部品はDIYを捨てて共通化せずに
画面とファイルが1対1の関係で使い捨てた方が絶対いい
コピペだってDIYだろ
画面だけは無闇に動的変動要素だらけにせずに直書きの方がメンテしやすい
バックエンドは共通化すべきだが ディレクトリ構造ってのはアプリケーションアーキテクチャの設計を反映したものなんよね
開発者にとってはディレクトリ構造がコードレベルでアーキテクチャを理解するための第一歩 >>9
一般的には抽象クラスやインタフェースや実装クラスみたいな形式的種別でどのディレクトリに置くかを決めたりしない
各ファイルが持ってる責務で決める >>11
その理屈だとテストディレクトリなんてものは作らずに
ソースコードと同じ所にテストコードも置くべきということになるが? >>14
テストコードの責務をなんだと思ってるの??? >>15
インターフェースの責務をなんだと思ってるの? なるほどなー 責務という言葉だけでは理解できない人もいるんだな
勉強になったわ 責務は能力と権限をセットにしたもの
テストとテストでないプログラムは機能も実行タイミングもアクターも違うので
分けていいと思うけど、パッケージプライベートのクラスをテストするために
クラスパスを同じにすることはあるよねー ■ このスレッドは過去ログ倉庫に格納されています