菊池 Blog

移転しました 続・菊池 和彦の足跡

AILight Banner
AILight Blog

プロフィール

菊池 Blog

目次

Blog 利用状況

記事分類

過去の記事

タグ

泣き言なんてききたかないね!

「仕様が決まってないとコーディングできません!」

「泣き言なんてききたかないね!」

 

って訳でドーラ一家のプログラマとして仕様が決まっていないコードを書く事になった私です。

public class Product<TCurrency>
{
    public string Name
    public TCurrency UnitPrice;
}

public abstract class Sales<TAmount,TCurrency>
{
    public Product<TCurrency> Item;
    public TAmount Amount;
    public TCurrency Price
    {
        get
        {
            SpecifiedCurrency price;
            CalcPrice( ref price );
            return price.Value;
        }
    }
    public abstract void CalcPrice( ref SpecifiedCurrency price );
}

public partial class SpecifiedSales
{
    public override void CalcPrice( ref SpecifiedCurrency price )
    {
        var amount = Amount;
        var unitPrice = Item.UnitPrice;
        var priceValue = amount * unitPrice;
        price.Value = priceValue;
    }
}

というわけで、できたできた。

// 仕様決まったら決まった型にする
using t_Amount = int;
using t_Currency = int;

// 仕様依存する型定義
public partial class SpecifiedSales : Sales<t_Amount,t_Currency> {};
public struct SpecifiedCurrency {
    public t_Currency Value;
}

って事でどうでしょうかね。

partial class + generic = template ? のコードからちょっと考えたら property の getter を実装する事ができました。

無駄に var を使ってますけど、あそこでは var 以外では表現できないって事を強調する為のものです。

 

本来、仕様の決定はできうる限り遅らせた方が良いのです。

そして、決定していない仕様に対してもコードを書けたほうが良いのです。

投稿日時 : 2007年12月28日 15:53


コメントを追加

#  re: 泣き言なんてききたかないね! 2007年12月28日 16:21 囚人

おー、なるほどねー。
新しい C# の世界って感じですね。

#  re: 泣き言なんてききたかないね! 2007年12月29日 12:07 えムナウ

>本来、仕様の決定はできうる限り遅らせた方が良いのです。
通常データベースドメインの決定は概念設計か論理設計で行われます。
設計理論として「できうる限り遅らせた方が良い」の根拠はどこにあるのでしょうか?

#  re: 泣き言なんてききたかないね! 2007年12月29日 14:16 菊池

>通常データベースドメインの決定は概念設計か論理設計で行われます。

 複数の顧客へ展開する場合において、各顧客に対してサイジングを検討しないとデータベースドメインは確定しない(できない)と思いますけどどうでしょう?

 根本的に密結合/疎結合の判断とは、どれだけの仕様要件に依存関係があるかの判断ですから多数の仕様に依存している設計は結合性が密であるという事になります。
 変更することによって多数の修正が必要となる仕様は当然に結合性が密であった事を意味します。

 システムの各部分との結合性はできるだけ疎とするべきである事について根拠を示すのは大変ですので割愛しますが、DBも「システムの各部分」の中の一つである事は事実で、密に結合して良いわけではありません。

 設計論としてはDBとも結合性を疎としたほうが良いのは自明です。
 結合性を疎にするコストが(パフォーマンス面等)これまでは我慢できないものになる事が多かったので、結合性が密にならざるを得なかったわけで、密に結合している状況においては依存される側を先に仕様決定しなければならないのでDBは先行して仕様決定されていたわけです。

 要するに結合性を疎にしづらかったのであきらめた結果として先に仕様決定せざるを得なかったからです。
 結合性を容易に疎にできる様になればDBを先行して仕様決定する必要はないのです。

>設計理論として「できうる限り遅らせた方が良い」の根拠はどこにあるのでしょうか?

 簡単な問題です。
 ここに「1年前に決定した仕様」と、「ついさっき決定した仕様」があります。現実世界の事情に近いのはどちらでしょう?

 仕様を決定するという事は一種の未来予知のようなものです。決定時点以後も周辺環境は変化をし続けます。
 
 決定時点からの周辺環境の変化という物を考えた場合、早期に決まった仕様ほど周辺環境との乖離が激しいという事になります。
 ある程度乖離しても動くよう安全度をとって仕様は設計されると思います。
 この安全度には当然にコストが付きまといます。安全度をむやみに大きくしてあげれば永遠に近い期間を経ても仕様は現実世界とマッチし続けるかも知れませんが、そのコストが我慢できるかを考えなければならないでしょう。

 現実世界、周辺環境に最も合致した仕様を作り上げるにはシステムを現実世界に送り出す時期に近ければ近いほどよいのは自明でしょう。
 仕様の決定はできうる限り「現実世界に送り出す時期に近づけた方が良い」=「遅らせた方が良い」のです
タイトル
名前
URL
コメント