ひねくれて作ってみましたが考察点がありました。
前回ネタ FizzBuzz問題を解いてみました、ひねくれてる? : http://blogs.wankuma.com/ognac/archive/2007/11/05/105950.aspx
( 元ネタ : http://blogs.wankuma.com/episteme/archive/2007/11/04/105829.aspx )
このときは、1行化とは反対に、膨らます意図で書いたのですが、振り返るとこのネタは奥がありますね。
仕様は、 "3,5,3*5(最小公倍数)の剰余が0のとき判定" と" そのときの表示文字" これだけです。
拡張性を考えれば、判定条件と表現値の組の増減は考慮しておくべきでしょう。増減の度にソースを触りリコンパイルするのでは芸がありません。
条件文の追加や定型化されているべきだと思うのです。この場合は、割る数と表示文字列の組になります。
その面から見ると、ひねくれて作った物ですが、イケてそうに見えるから勝手なものです。
(1) 元の和の範囲 1～100 : 上限下限は業務ルール依存値
(2) if n mod 0 = 0 then 出力文字 = "xxxxx" の判定式自体は 業務としては固定式
(3) n と xxxxxx は業務ルール依存値
三種類の違う性質の物を同列に記するより、分離したほうが、保守性は高まります。(1)、(3)を外部File化すれば、ルール変更はユーザーに任せにできる(かも知れません)。
クラス設計とインスタンスの保持のコレクションの大切さを改めて見直した次第です。
(2)の部分を外出ししてしまうと、飯の種が無くなります <=オイ
ビジネスルールのパターンの増減は有り勝ちな事で、言語のソースに埋め込むのは考え物です。
例) 割引率の設定
お買い上げ個数
1個～10個: 0%off (定価販売)
11個～20個: 10%off
21個～30個: 15%off
31個～40個: 20%off
40個以上 : 30%off
表にするのが可能なケースはRDBで持ってもインスタンスで持っても良いので、ソースは不変で対処できます。
この条件に、 25個以上は、売価の10%のクーポン券をつけることになったら、結構面倒ですね。
ソースを弄ることになります。この部分をカプセル化して外出しするかしないかは、アプリの規模にもよるので
一概にいえませんが、変更に強いシステム設計というのは、小さい部分から心がけて設計しないとダメだと思うのです。
(*) FizzBuzz問題では 3,5では 15の倍数(3*5) でいいのですが、任意の数の時は最小公倍数にする必要があり(**)、少し工夫がいります。
(**) コメントありがとうございました。