オブジェクト指向超入門〜第３回〜

前回説明したように、構造化プログラミングのスタイルを取り入れてシステム開発を行えば生産性が上がってみんなハッピー！と考えてしまいたくなりますが、実は問題点があります。

問題点その１〜日付は常に正しいか

こんなコードを書いたとしましょう。
today.mm = 13;

この後 dateDiff(birth, today); という関数呼び出しを行うと何が起きるでしょう。このように予期しない値が変数に格納されている場合、何が起きるかは一般的には予見できません。最悪の場合システムがクラッシュします。
悪いのは誰か。月に13を代入する奴が明らかに悪いと片付けるのは簡単です。さすがにこんな明からさまな例を出されても納得できない人もいるでしょうが、代入する値がどこか遠くからやって来た変数である場合など、予期しない値が代入されるケースは十分有り得る、というのはプログラマなら理解してもらえると思います。

問題点その２〜日付は年月日の３つの値を持つのか

例えば、２つの日付の差分日数を簡単に求めるために、MyDateの定義を変更したくなったとします。

struct MyDate {
　　int yy; // 年
　　int ddd; // 1月1日からの通算日数
}

こんな感じ。そして dateDiff() 関数の中身を今よりもシンプルに書き変えます。
このような変更はプロジェクト全体にとって大騒ぎですよね。today.mm = 12; などとやってる箇所を全て探して修正して回らなければいけません。
これもいかにもな例ではありますが、要はいったん構造体を定義してみんながそれを使い始めてしまったら「ここはもっとうまくやれたのに」と後から後悔しても、もう変更は効かないという事です。

問題点その３〜共通関数は使われているか

ライブラリ内の共通関数を呼べば余計な処理を書かずに済むと言われても、システムの全ての箇所でそのようなコードになっているでしょうか。共通関数を呼ばずに自前で処理を書いている箇所が無いという保証はありません。「そんな揚げ足取らなくたって　みんな分別ある大人なんだし」と果たして言えるでしょうか。プロジェクト内には恐ろしいコーディングをしてくれるプログラマが実在します。配属されたばかりの新人君もいれば、破壊的なコードを書く天下無敵のヘボプログラマも本当にいるんです。
オブジェクト指向には個々のプログラマの分別なんてものはハナから信用しないという考えが根底にあります。

タグ ：
#オブジェクト指向