外部と内部を分けることの弊害

COBOL屋の呪縛に、ちょいと補足。
COBOL屋の呪縛ではフラグの話を書いたけど、フラグ以外の属性でプログラムの挙動を制御するのもCOBOL屋さん以来の伝統かも。極端に簡単な例で説明。

user = User.find(id)
do_something_for_admin if user.category == 'admin'
do_something_for_manager if user.category == 'manager'

継承を使えばif文は不要になる。それだけテストが減る。(この例は簡単すぎてテストの減らしようがないけど...)[*1]

class Admin < User
  def do_something
    # do_something_for_admin
  end
end

class Manager < User
  def do_something
    # do_something_for_manager
  end
end

User.find(id).do_something #これでよい

RailsSingleTableInheritanceをサポートしているので、usersテーブルにtypeという文字列カラムを用意しておけば、上記処理は簡単に実装できる。あと、テストがAdminとかManagerとかの単体でほとんど終わってしまうのも良いこと。「連結させないとテストできない」っていうのは、不具合がでたときの戻りもでかくなるので好ましくない。別にRubyでなくても、オブジェクト指向っぽい言語なら大体話は同じはず。

外部設計と内部設計を分ける弊害

で、こういうのってウォーターフォール的には「内部設計」に分類されるらしい。なので、「外部設計だけ」をする人達には「おら知らね」という世界になる、と。外部設計は「ユーザに見える世界の話」なので、データ構造も論理構造までしか考えないのが普通(らしい)。だからCOBOL屋の呪縛に書いたようなフラグ立ちまくりのレコード配置とか、上に書いたような「ユーザカテゴリ分類」みたいな所で思考が止まってしまう。(そりゃそうだ。ユーザには継承だとかM:Nリレーションだとかは関係ないわけだから。)

でも、同じ論理データ構造から様々な物理データ構造が考えられ、当然それは実装にも影響を及ぼす。乱暴に書けば以下のようになる。

  • 論理構造をそのままCOBOL的に実装すれば、コードは汚くなってテストも大変になる。
  • ER分析するけどOOしないのなら、コードはそこそこきれい。テストはそこそこ大変。
  • OO実装すれば、コードはきれいになりテストも楽になる可能性がでてくる。

外部設計とか内部設計とかで分業しちゃうと、外部設計の人はOOはもちろん、下手したらER分析も「実感のない世界」になってしまう可能性がある。COBOL時代の文化が引き継がれるのは、このあたりに理由があるのかも。

あたりまえじゃん

と、わかる人はいうであろう。問題は「わからない人達にはわからない」、ということ。わかってないことをわかってない。うー。

おまけ

http://pc11.2ch.net/test/read.cgi/db/1069324950/

742 :NAME IS NULL:2007/01/06(土) 16:07:12 ID:???
カラムが200も300もあるテーブルを作りまくってたり
必ずFILLERがあるとかw

まあ単に勉強不足なだけなんだよね
しかし無知であるのは仕方ないとしても勉強する気がないのは最悪
仕事なんだからさー
主キーのないテーブル云々ってのも結局そこに起因するのが殆どな気がする

*1:adminでもmanagerでもない場合のテストが減らせる。あと、継承以外にも手段はある。やたらと継承かけるのも問題よん。