OOコード養成ギブスのコメント欄の和訳 その３
Binstock on Software: Perfecting OO's Small Classes and Short Methodsのコメント欄より。OOコード養成ギブスのコメント欄の和訳 - @katzchang.contextsの続きのOOコード養成ギブスのコメント欄の和訳 その２ - @katzchang.contextsの続き。
Paul Keeble said...
えっと、この練習をやったあとにどうなるかは面白そうだね：
- 作ったクラスは小さく多数になる。同僚が作るよりも、桁外れに。
- 再利用性が高く部品化された状態で仕上がる。
- 作ったドメインモデルには、作ってもない多数の拡張機能ができるし、多分二度と作らない。
- 2つしかインスタンス変数を持たないルールは、2回破る。出来るかどうか検討するために。
- getterとsetterがなくても寂しくなくなる。
- ビジネスコードの"Micro reports"はずっと問題になってたが、getterなしで書くとロジックと結合させられるので、全く必要なくなる。
個人的には、プログラムは短くて済んだかも知れないけど、ナイスでシンプルにユニットテストが出来るだろうし、理解しやすくなると確信できる。
そのコードは自分が普段書いたのとか一般的なものは違う感じだろう。この練習で上達したような気はするし、お勧めするよ。
言語構造にとって、係り受け超重要。
引用部、もっと良い訳はあるだろうけれども。
Net Pryce said...
面白いけど、オブジェクト指向にマッチしないのがあるね。手続き型言語での抽象データ型っぽい。オブジェクト指向言語で常識のルールに触れるのは1つじゃない。多態とか。
こんなルールはどう？："else"だけじゃなく、"if"も使うな。
羽生さんが「if撲滅」って言ってたのを思い出した。
Ixulai said...
データベースの正規化問題と同種に見える。
第5正規形は知識として知っておいた方がいいけど、常に使うべきとはいえない、みたいな。
使いやすくて保守しやすいように非正規化する練習があるといいね。
第5正規形は、http://www.atmarkit.co.jp/fdb/rensai/db_enginer03/db_enginer03_4.html#10。エンティティの属性を分割する、みたいなやり方で、プリミティブを直接使うなとか、インスタンス変数は2個まで、とかの制約と、確かに似てる。
LOC pollution(local pollution)は、何か有名なアンチパターン？
ようやくご本人の登場。
多態よりもカプセル化という立場。
Nat said...
超知ったかぶりするけど、このルールで考えさせられるのは「データ隠蔽」で、「カプセル化」じゃない。直交する概念だよ。
冒頭の節「To be super pedantic, ...」は、謙遜のニュアンス？一般的にはデータ隠蔽によってカプセル化、だけど、どういうことだろか。
Christain Vest said...
@binstockへ、上限50行の件。
実際のJavaコードだけを数えて、Javadocの行数は50行にカウントしないとしたら、負けだね。エディタの画面にフィットするから良いっていう理由がないし。もちろん、javadocで自動改行を使うか、全メソッドに対して価値あるドキュメントを作るとしてinterfaceにjavadocをつけるか、どっちにしても綺麗じゃない。どちらもでっち上げの自傷行為への逝かれた答えだ。前者はloop-holeっぽいし、後者は…どうだろう。どっちにしても良いとは思わないし、まぁともかく、Qi4jとかのコードスタイルになるだろうね。初心者にオブジェクト指向を叩き込むのには良いんじゃないかってコメントもある。それなら、javadocを書かない前提ってのを明示した方がいい。初心者にとって、この制約に従う方が、javadocを書く癖をつけるより重要ならね。
厳しいご意見。
