［アーキテクチャ編］巨大な定数クラスを作ってはいけない
定数クラスについての指針は，アプリケーション開発指針などに簡潔に記されていることが多い。大規模プロジェクトであるにもかかわらず，役割や目的に応じた定数クラスの分割方針が示されず，単に「定数に関しては，分散しないよう定数専用のクラスを用意する」などと記されている場合は，一つの定数クラスに全定数の定義が集中し，巨大な定数クラスができ上がってしまう。 実装者の作業効率が悪化する 通常，定数クラスの利用者となるプログラマが必要とする定数は，一つないし数個に限られる。プログラマが，図2のような巨大な定数クラスから，必要な定数を探すことを想像してほしい。 【Javaの場合】 public class Construct { /** 処理結果コード : 対象なし */ public static final int NOT_FOUND = -1; /** 処理結果コード : 正常 */ public s
CakePHPを使ったMVC設計のベストプラクティス - Sooey
CakePHPを使ったMVC設計のベストプラクティス 個人的にはCakePHPはあまり好きではないのですが、CakePHP開発メンバーによるMVCデザインの記事 (CakePHP のおいしい食べ方)で紹介されていたBest Practices in MVC Design with CakePHP (php|architect’s C7Y)はMVCフレームワーク利用者にとってとても有用な情報だったので、訳してみました(php|architectの方には翻訳許可を頂いています)。 この記事を読んでドメインモデルに興味を持った方は、エンタープライズ アプリケーションアーキテクチャパターン(PoEAA)やDomain-Driven Design: Tackling Complexity in the Heart of Softwareに手を出してみるのもいいかも。他に、InfoQにユーザー登録すれ
プロセス図の描き方とお作法--実は超簡単 !
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 前回は、仕事にプロセス志向を適用し、仕事の流れを図として「見える化」することで、改善すべきポイントがどこにあるかを把握しやすくなることを説明した。この「プロセス図」は見る人にとって理解しやすく、仕事の流れを正しく表現できているものであれば、実際にはどのように描いても差し支えない。 ただ、そうした図を描くときに覚えておくといいルールや、図を他の人と共有する場合に、より都合のよい描き方というものが存在する。まずは、それについて紹介しよう。 図でコミュニケーションのギャップを埋める 先ほど「どのように描いても差し支えない」としたが、実際に仕事の流れ図を描くとき、自分流に描いてしまうと問題が起こるケースもある。たとえば、後で複数の人が集まって図
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
