『オブジェクト指向入門 第2版』の19章を読んだ

19章　方法論について

方法論の原則

理論的根拠

ソフトウェアの方法論に関するルールは対象に関するある1つの理論に基づくものでなければならない．

実践的根拠

ソフトウェア方法論のルールは広範囲にわたる実践的経験による裏付けがなければいけない．

再利用の経験

専門家の位置を主張するためには，その分野のどこかで中心的な役割を果たしていなければならない．

規則の分類

絶対的な肯定：「常にaをせよ」

方法論に関する規則を考えるときは，絶対的な肯定を優先すること．ここに含まれる規則を，ツールや言語構造で矯正することが可能か検討せよ．

絶対的な否定：「絶対にbを採用してはならない」

絶対的な否定には，なぜそのメカニズムを採用してはいけないかを示す厳密な説明が必要である．また，その説明には，禁止するメカニズムの代わりになるメカニズムや方法についての厳密な説明が伴わなければならない．

助言に関する規則

• 助言的な肯定：「可能な限りcを採用しなさい」
• 助言的な否定：「可能な限りdを避けなさい」

助言的な規則（肯定，否定関わらず）を作るときには，決まり文句ではなく，原則を使うこと．例えば，「意味のある変数名を使え」は原則ではなく，決まり文句である．なぜなら，誰も意味のない変数名を使うことを勧めたりしないからである．これを原則にする場合は，変数名を決めるための厳密な基準を定義しなければならない．

• 何をしているのかを理解していないならば……
• 絶対に必要でない限り……
• なるべく……しない．

などといった助言的な否定がたくさん必要になるとき，ツールに問題があるといえる．

所感

「常にaせよ」というなら機械的にやった方がいいというのは当たりだけど，「常にaをやる必要がある」と「ツールを導入しよう（機械的にできるようにしよう）」という考えが繋がらないときがある．今後は，常にやるなら機械的にやる（機械的にやらないことは必ずしもやる必要はない）という思考ができるようにする．

断定できるほどの情報がない，情報を整理するのが面倒といった理由で，助言的な肯定・否定をしてしまうことがある．確かに，「できるだけdしない方がいい」という主張には，「dする代わりにどうするの？」「dするときってどんなとき？」という疑問がついてくる．これに答えられるなら，「Xするとき以外はdしない」と絶対的な否定ができる．主張に曖昧さがあるときに助言的な言い回しをしてしまうと思うので，できるだけ裏付けを考えて主張するようにしないといけない．