5年後に後悔しないJavaプログラムの書き方 - L'eclat des jours(2009-07-02)

_ 5年後に後悔しないJavaプログラムの書き方 ここ数日、死ぬほど後悔しまくっているので、あらためて（というのは、数年前にも一度後悔しまくって、そのときの知見はあらかた処方箋とかコーディングの掟に書いているからだが）後悔しないための書き方をいくつか紹介する。 とにかく、ファクトリメソッドパターンを使うこと。 これは本当に重要。しかも簡単でありながら効果は絶大。 だめな例。 public class FooBar { private Connection conn; ... protected void setup() { ... conn = DriverManager.getConnection(url); ... } urlを指定することや、DriverManagerの実装を交換すれば良いだろうと想定していても（というか、Connectionならそういう方法もあり得るが、そうはいかな

[ArcWaterCash]

java　デザインパターン　プログラミング

[maraigue]

プログラムが長期にわたって使われるために考慮すべきこと

[schrift]

　ファクトリメソッド。

[tl_bkmk]

刹那的インターフェイスを避ける

[lizy]

DIとかファクトリメソッドに関しては「テストを書くこと」でいいんじゃないですかね。テストを書こうとするとMockとかの関係でどうしても実装を差し替えられるような仕組みが必要になってくる

[koumiya]

フィールドはパッケージプライベートにすること！カプセル化とかあんま意味ないけど、デフォルトスコープはテスト書くときも楽だよね。あとは、なんといっても正しい名前をつけること！

[seiunsky]

「オブジェクトの利用方法はオブジェクトに任せる」そーいうもんなのかなー。自分はオブジェクトが別のクラスに依存しちゃってイヤンな気持ちだけれども・・・（や、この利点も良くわかるけどね）。

[zephyros]

Java

[inouetakuya]

他にもたった一つのfinalメソッドのために、クラスをまるまるコピー&ペーストして別クラスを作らざるを得ないというような例もある。というわけでfinalも極めて刹那的なインターフェイスだ。

[bobokov]

チンプンカンプンだけど保存

[yasu-log]

これの多言語版が読みたい。特にアクションスクリプト。

[taka_zyawa]

参考

[thesecret3]

javaはアーキテクチャに凝りすぎになりがちなので「アホみたいでも、ただそこに書く」というほうがいい。

[mousecat]

骨組み部と肉付け部は完全に分離する。骨組み部は繋ぎ換えしやすくする。それだけ意識すれば大抵何とかなっている。特にUIの大規模変更作業などでは楽できておいしい。

[kenichiice]

「5年後に後悔しないJavaプログラムの書き方」

[utanaka]

やっべ、Java全然思い出せない；；

[literturehardcore]

覚える

[takuya5455]

他にもたった一つのfinalメソッドのために、クラスをまるまるコピー&ペーストして別クラスを作らざるを得ないというような例もある。というわけでfinalも極めて刹那的なインターフェイスだ。

[te2u]

Java使わなくなって久しから、的外れになるかもしれないけど。/SRPに違反している気がする。Connectionを取得するためのインターフェイスを定義して、その実装でDriverManagerとMockConnectionに分けたらどうだろう。

[otchy210]

思い当たる節が…。パッケージプライベートはあまり活用した事無いな。

[yukung]

ファクトリメソッドパターンを使え、とか。

[kazf]

「フィールドはパッケージプライベートにすること」以外は同意　テストでモックと差し替えたいならprotected Connection getConnection()で十分

[nobeans]

DI時代の前に書いたコードではJUnitでモック化するためにファクトリメソッドを全面採用した。本流じゃないよなぁとか思ってたけど、こうやってプッシュされるとちょっと嬉しい。

[InoHiro]

”とにかく、ファクトリメソッドパターンを使うこと”

[pyawk]

リファクタを想定したコーディングって大事だよねぇ

[masayang]

う〜ん　この記事でパターン濫用者が増えない事を祈る。　大事なのは５年後に後悔しないことではなく、後悔しそうになったら常にリファクタリングすることではなかろうか。最初から完璧なコードを書かない事。

[coppieee]

DIコンテナ使えばよくね？

[motemen]

"与えた情報を絞らせるように設計すべき"/"刹那的インターフェイスを避ける"

[suikyo]

ふむん…

[fuktommy]

ファクトリメソッドというか依存性の逆転原則大事。