31日間で学習ノート31を再構築する.条件判断の代わりに多態を用いる

要旨:最近リビルドのプロジェクトをしているため、リビルドについてもう一度学習と整理を行い、31日間のリビルドについて最初に接触したのは2009年10月で、当時はSean Chambersのblogを購読していなかったため、海外のコミュニティをぶらぶらしている間にリンクしたことがある.シリーズ全体を一気に見終わったのを覚えていますが、これらの基本的なプロジェクトは使用されていますが、私たちはそれを表示したり整理したりしていないので、あまり重視されていません.今突然この再構築プロジェクトを引き継ぐと、チームメンバーの技術と経験がバラバラになっているため、再構築の要綱を専門に整理する必要があります.もちろん、このシリーズも新しいシステムのコード規範の参考に適しています.コードの場所があれば、この再構築規範は価値があります.週末もぶらぶらしたくないし、この美しい町に着いたばかりなので、親戚や友达がいないので、2日間落ち着いてこの再構築の参考規範を書くことができます.Windows Live writerで文章を書く快感も感じました.もちろん再構築された全体的なアーキテクチャは別です(全体的なアーキテクチャは私のこの文章で専門的な説明があります(http://www.cnblogs.com/zenghongliang/archive/2010/06/23/1763438.html). 大きなアーキテクチャが設計された後、これらの再構築の細部点は東風の後の大火となり、プロジェクト全体にとっても重要である.31日間でこのシリーズを再構築するのは、「コード大全」、「再構築:既存のコードの設計を改善する」と比較すると、比較的簡単で分かりやすいのが最大の特徴です.では、私もこれらの文章はSean Chambersの31日間の再構築を学ぶノート整理なので、このノートに異議があれば指摘してもいいです.
具体的にはhttp://www.lostechies.com/blogs/sean_chambers/archive/2009/07/31/31-days-of-refactoring.aspx原文を調べる.
 
コンセプト:本明細書の「条件判断の代わりにマルチステートを使用する」とは、オブジェクトのタイプをチェックしたり、タイプに応じていくつかの操作を実行したりする必要がある場合、アルゴリズムをクラスにカプセル化し、マルチステートを利用して抽象的に呼び出すのが良い方法です.
 
本文:本稿では、オブジェクト向けプログラミングの基礎の一つである「マルチステート」を示します.オブジェクトのタイプをチェックしたり、タイプに応じていくつかの操作を実行したりする必要がある場合、アルゴリズムをクラスにカプセル化し、マルチステートを利用して抽象的に呼び出すのが良い方法です.
次のコードに示すように、
OrderProcessorクラスのProcessOrderメソッド根拠
Customerのタイプは、上記のように、それぞれいくつかの操作を実行します.
OrderProcessorクラスでは、これらのアルゴリズム(データまたは操作)は特定の
Customerサブクラス.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using LosTechies.DaysOfRefactoring.SampleCode.BreakMethod.After;

namespace LosTechies.DaysOfRefactoring.SampleCode.ReplaceWithPolymorphism.Before
{
    public abstract class Customer
    {
    }

    public class Employee : Customer
    {
    }

    public class NonEmployee : Customer
    {
    }

    public class OrderProcessor
    {
        public decimal ProcessOrder(Customer customer, IEnumerable<Product> products)
        {
            // do some processing of order
            decimal orderTotal = products.Sum(p => p.Price);

            Type customerType = customer.GetType();
            if (customerType == typeof(Employee))
            {
                orderTotal -= orderTotal * 0.15m;
            }
            else if (customerType == typeof(NonEmployee))
            {
                orderTotal -= orderTotal * 0.05m;
            }

            return orderTotal;
        }
    }
}

 

        ，  Customer           ，  OrderProcessor   ProcessOrder               。

 

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using LosTechies.DaysOfRefactoring.SampleCode.BreakMethod.After;

namespace LosTechies.DaysOfRefactoring.SampleCode.ReplaceWithPolymorphism.After
{
    public abstract class Customer
    {
        public abstract decimal DiscountPercentage { get; }
    }

    public class Employee : Customer
    {
        public override decimal DiscountPercentage
        {
            get { return 0.15m; }
        }
    }

    public class NonEmployee : Customer
    {
        public override decimal DiscountPercentage
        {
            get { return 0.05m; }
        }
    }

    public class OrderProcessor
    {
        public decimal ProcessOrder(Customer customer, IEnumerable<Product> products)
        {
            // do some processing of order
            decimal orderTotal = products.Sum(p => p.Price);

            orderTotal -= orderTotal * customer.DiscountPercentage;

            return orderTotal;
        }
    }
}

 
まとめ:「条件判断の代わりに多態を用いる」という再構成は、多くの場合、設計モード(よく見られる工場ファミリー、ポリシーモードなどに影が見える)が現れることが多い.これは、多くの条件判断を省くとともに、コード、仕様クラス、オブジェクト間の職責を簡素化することができるからである.