実装が終わってからプログラム説明書を書こう
設計書と説明書は同じもの!? 一般的な開発手法では、はじめにソフトウェアの設計を行い、設計書を作成する。ここで提案する手法では、更に、実装の後にプログラム説明書を作成する。 これらはいずれも、ソフトウェアがどのような作りになっているかを解説するドキュメントである。よって、この２つのドキュメントの内容は、まったく同じになる。 では何故、はじめに設計書を作っているのに、改めて同じ内容の説明書を作らなければならないのだろうか。 設計書と説明書では、読み手が異なる 実装の前に作成する設計書とは違って、プログラム説明書は実装の後で、完成したソフトウェアを元に作成する。同じプログラムの作りを解説するドキュメントであっても、実装の前に書くのと後に書くのとでは、出来上がる文章は、まったく別物になる。 設計書は、これからどのように実装するか、その指針を書いたものである。つまり、実装を行う自分自身のために作る
Template Methodパターン
親クラスの制作者 親クラスは、子クラスで変更できる部分と、できない部分を規定する。よって、親クラスの制作者は、将来作られるであろう子クラスをおおよそ想定して、子クラスでオーバーライドできる抽象メソッドを用意しておく必要がある。 子クラスの制作者 子クラスには、処理が異なる部分だけが記述されているため、子クラスだけを見ても、意図や存在意義が分からないこともある。 例えば、子クラスには、下記の１行だけしか書かれていない、ということすらある。 子クラスの制作者は、親クラスの作り、特に、Template Methodはその実装まで、強く意識する。 クラスの利用者 利用者は、Template Methodパターンになっていることは、ほとんど意識しない。 利用者はたいてい、子クラスを直接使う。呼び出すメソッドが、実は、処理自体は親クラスでTemplate Methodとして実装されていて、子クラスでは
複雑なアプリケーションの機能仕様は、概念モデルで整理しよう
機能豊富なアプリケーションの開発では、機能仕様の策定にもかなりの時間がかかる。特に、画面にたくさんのボタンが置かれていたり、いくつもの画面を並行して操作できるような、操作性の複雑なアプリケーションになると、ユーザインターフェースの機能仕様をまとめるだけでも、極めて大変な作業となる。 顧客からの要求仕様では、画面のレイアウトと、基本的な操作の手順が示される。開発者は更に、顧客が想定していなかった例外的な操作や、いくつかの機能を組み合わせた複合的な操作をした時の挙動についても、明確に洗い出して、機能仕様としてまとめなくてはならない。 考えうるユーザ操作の組み合わせは膨大な数に上るため、機能仕様の策定には時間がかかる上、思考も混乱しがちだ。たとえあらゆるケースを想定して挙動を定めたつもりでも、矛盾や洩れのある仕様になってしまうことも多い。このような不備は、テストになってから不可思議な動作をするこ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
デザインパターン
