wildcatsの日記

赤羽在住でIT関係の会社の社長やってます。

Design

トラックバックに対するレス

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

失敗

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

Webサービスクライアントの実装

だったらインタフェイスと実装は分けます。 システムの境界を超える(他システムへのアクセス)のであれば 仕様と実装を分離することに意味があると考えています。

画面表示のロジック

例えば正解・不正解を画面に表示するために データベースのカラムがtrueならば○、falseならば×を画面に表示する仕様があったとして 皆さんならどのレイヤにこのロジックを入れますか? A) DomainModel B) DomainLogic C) ApplicationLogic D) Service E) Fac…

変更可能性

昨日書いた変更可能性の話でnekopさんからリアルツッコミあり。 「どの部分に変更が入りやすいかって経験やと思う」 う〓ん。もうちょっと頭の中がまとまったらなんか書くことにする。

アホなエントリを書いた。

昨日のエントリのYAGNI云々は本当にアホなことを書いたと職場で思いました。 というのはYAGNIってシンプルな実装を目指すであって 単純な実装のことを指しているわけではないように感じたからですね。 例えばボクはif文のネストで分岐を表現しているコードを…

カカク・コム

ボクもみました。<ガイアの夜明け モロにデスマーチの匂いがした特集でしたね(w ちなみにサーバマシンの調達の話があって おとといにカカク・コムで検索していたんですが そしたら「不正なシステムコードを認識しました」ってエラー画面が。 そもそも不正…

独り言

少し前からだけど「YAGNIと変更可能性を考慮したソフトウェア開発」のバランスについて だんだんと境界がわからなくなってきた。。。。 そもそも開発段階で「変更が入りやすい箇所」の判断はどうするのか。 お客さんが「ここは将来変わりそうだよ?」という…

第4回 フィーチャの実現法とサブジェクト指向パラダイム

(via ひがさんの日記) これも後で読んでおこう。

Separation of Hotspot

(via nekopさんの日記) 寝起きで頭がボーっとしているがメモ。

Synchronizing Data Access Object

メモ。

パッケージ設計

自分が担当になったので いつもはMeyer本を持ち歩いているのですが 今日は「アジャイルソフトウェア開発の奥義」をカバンに入れてきた しかしこの本重いな〓

冗長なエラーチェック

年末にDbUnitをいろいろいじっていてフォーマットをFlat/XML以外にもExcelに対応させようといろいろ触っていたときのこと Antのタスクコード中で"xml"or"flat"以外だったら例外になっていたコードがあったんで そのコードを修正してjarを生成して再実行した…

限定的な型

以前の実践J2EEシステムデザイン読書会で 型をきっちり定義すべきだという話をした記憶があり その後にいろいろと考えていたのですが DTOのメンバや引数の型を限定的にするのは少し問題があるように思いました。 理由としてDTOのsetterを呼び出すのは基本的…