確かにjarに実装ファイルを入れておいて オブジェクト指向設計原則のISPを実現するのは有りだな。 問題は同パッケージで同クラス名のJavaファイルを如何に管理するかか。

インターフェイスそのものの効果はない場合（パターンとか）でも、単純にC++のヘッダファイルのような役割を果たせる。インターフェイスを必ず書いて、そこにjavadocを書く。具象にはコメントしか書かない。これは私も良くやります。具象クラスには@seeコメ…

ちょっとしたツールを自社で作ってて ドメインモデルへの責務の持たせ方でSRP違反なクラスでかつ依存関係が双方向になるモデルを作っちゃいました。 うーん。いかんな。。。かなり勘が鈍ってる。気づくのが遅すぎる。

(via オレンジニュース) これすごくうれしいテーマかも。オージスさんやるな。 つーか、いきなりｷﾀ─ｗｗﾍ√ﾚｖｖ〜(ﾟ∀ﾟ)─ｗｗﾍ√ﾚｖｖ〜─ !! こうしたドメインモデル探究の過程では、当然ドメイン知識をもった専門家との対話が不可欠です。開発者と専門家の間…

ボクはレイヤって関心の分離とか抽象化を促す目的で採用しています。 もし再利用性を高めたいのであればレイヤ化するだけではなくパッケージの依存関係に目を向けないとダメかもしれません。 というかシステム境界を超えた再利用ってユーティリティパッケー…

オブジェクト指向入門第二版発売を記念してちょっと書いておく。

第2版は、第1版の約3倍、1900ページ以上のボリュームで、「原則・コンセプ ト」と「方法論・実践」の2分冊(1分冊約960ページ)になりました。1900ページかぁ。。。。。(^^;;;;;

2006年12月06日 ELLEGARDEN java, program ていうかゴミのような空クラスが大量に生成されているのはダサいよね。そうそう。Interfaceの抽出がどうこうよりも過去に見かけたことがあるのですが 更に空クラスを継承してたりするのはもっとゴミですかね。

実装に特性があるからインタフェイスと実装を分離するわけで*1 インタフェイスに対して実装が1クラスになる場合にはインタフェイスと実装を分離する必要が無いとボクは思うね。 *1:例外としてはDynamic Proxyを用いたいから分離するケースはあると思う

池袋のジュンク堂に先々週に2冊程あったと言う情報があり。 買ってない人は急げ！

「ネタにマジレスせんでもええか」と思ってたけど一応書いとく。 何が「まずい」と思ったのか。 自動販売機と商品の関連についてです。 ・自動販売機を生成するために商品は必ず必要なのでしょうか？（これはシステム範囲によるのかも） ・自動販売機内に内…

また＠ITか！と言う話はおいといて とりあえず Vending drink = new Vending("Coffee", 130);これは例としてまずいと思う。 後で時間があったらコメントを書く。 追記：ちょｗｗｗｗｗ誰だよ。コメントを書く前にはてぶに追加したのはｗｗｗｗｗ

とても参加したいのですが、リリース前日なので無理です。。。。。

id:chung-zeeさんのコメントから うん。これはそう思いますね。 この前もウチの会社で私達が作業をした後の作業を 自称「設計ができる外注エンジニア」が対応した話ですが 「Facadeパターン」を使って実現している部分を何度説明しても 「Facadeを実現するた…

(via JavaBlackさんの日記) これはひどい...... JavaBlackさんの日記でかなり叩かれてるけど 一番ひどいな〜と思ったのはこの部分。 ここでは，オブジェクト指向設計を支える「デザインパターン」とは何かオブジェクト指向の特性(多態性とか）が「デザインパ…

なお、当初「オブジェクト指向」は、この“オブジェクトへのメッセージ送信”を意味するものであったが、後に C++ の設計者であるビアルネ・ストラウストラップが 1986年に発表した“抽象データ型のスーパーセット”という「カプセル化、継承、多態性」に代表さ…

ぐぐってて見つけた。 さて、Robert C. Martinは、この原則をさらに現代的に言い換えています。 クラスに変更が起こる理由は、一つであるべき。 A class should have only one reason to change. 「変更」に焦点を当てた定義は、より具体的です。もし、変更…

(via ちくわプログラマの作業履歴) なんか昔メモったような記憶があるな....

JavaとC++のどちらも引数の型をcontravariantにしてオーバーライドすることはできないためList30はコンパイル・エラーとなってしまう。 これはたまにTigerでサポートされているものと思って書いてみて あれ？なんで？って思っちゃいます。 引数の型を反変に…

izuオフの時にid:koichikさんから話がありました。 あとできっちり読んでおきますです。

(via たかはしさんの日記) 連休中に読むことにする。

現場でDepenjency Injectionパターンの説明を行う場合に 最初は依存関係有りまくりのコードを書いておき欠点を挙げておいて 依存関係を外に出してから仕様と実装の分離を適用して Factoryメソッドに置き換える説明をしてました。しかし、この図はいただきで…

どっかのえろい人が考えたソフトウェアパターン通りに設計や実装を行う人達がいる それ以前になぜプログラムが必要かを考えさせるのが重要だと思った

取り上げていただきありがとうございます。 でも、全体的にはあまり理解できていなかったかも。自分もおそらくあまり理解できてないと思います。 １人で読んでも理解が乏しいのでいろんな人の見解が得られる 読書会を開催しているというわけです(^^;

反応ありがとうございますm(__)m まだ３章までですが、かなり良書の雰囲気。圧巻は7章です（某id:koichikさんと同じやなぁ)。自分は本を読む前と読んだ後で価値観が変わってしまいました。 あとは10章と11章ですかね。

今日、第一回の開催予定です。 id:egapさんとid:nasobemeさんと語り合ってきます。

分かってる人達が「これはいいね」「今度こそいいパラダイムだ」とか言って満足してるだけ．あはははは(^^; ちょっと前に同じようなことを考えていました。 新しいパラダイムって理解してもらえないと現場から激しく抵抗されるだけなんで 提案する意味がない…

やべ。。。幹事なんだから場所の予約取らなきゃ(^^;;;;;;;;;

スーパークラスがアルゴリズムの不変な部分を定義するためだけに存在するのなら Template Method パターンの適用は妥当と言える。これで納得。以前のプロジェクトでTemplate Methodパターンの適用箇所を間違えていたということだと思いました。 でもid:m-has…

個人的にずいぶん昔に業務のフレームワークを作っていてひどい目にあったことがあります。 あまり深く考えずにTemplate Methodパターンを用いて 親クラスの責務で制御を行い 子クラスの責務で業務部分の差分実装という形にしたのですが 子クラスが肥大化し重…