뻥 튀기 디자인 모델 - 단순 공장 모델

먼저 작가 의 원문 을 발췌 하 다.
디자인 모델 의 네 가지 경계:
1. 배우 기 전에는 잘 모 르 겠 지만 디자인 모델 로 디자인 한 코드 가 엉망 일 줄 은 몰 랐 습 니 다.
2. 몇 가지 모델 을 배 운 후에 매우 기 뻤 습 니 다. 그래서 여기저기 서 자신 이 배 운 모델 을 사용 하려 고 했 기 때문에 여러 가지 모델 을 잘못 사용 하여 자신 도 모 르 게 만 들 었 습 니 다.
3. 완전 부 모델 을 배우 면 여러 모델 이 매우 비슷 하고 모델 간 의 차 이 를 구분 하지 못 하 며 곤 혹 스 럽 지만 오용 의 해 를 잘 알 고 응용 할 때 망 설 인 다.
4. 각종 모델 을 유연 하 게 활용 하고 심지어 구체 적 인 특정한 모델 을 사용 하지 않 아 도 우수한 코드 를 디자인 할 수 있다.
 
뭐 예요?
간단 한 공장 모델 은 들 어 오 는 데 이 터 를 통 해 몇 가지 가능 한 종류의 인 스 턴 스 를 되 돌려 주 는 것 이다.그러나 이 몇 가지 종 류 는 일반적으로 하나의 공 통 된 특징 이 있 는데 이 몇 가지 종 류 는 모두 공 통 된 부류 와 공 통 된 방법 이 있 지만 모든 방법 이 집행 하 는 내용 이 다 르 고 서로 다른 데이터 에 따라 최적화 된다 는 것 이다.
 
 
형상 화 된 예:
우리 가 아침 을 살 때, 아침 가 게 는 무엇 을 팔 고 있 습 니까?그 점 에 주의 하 셨 습 니까?많은 음식 이 거기에 놓 여 있 는데, 당신 은 판매원 에 게 어떤 음식 을 원 하 는 지 만 말 하면, 그 는 당신 에 게 어떤 음식 을 가 져 다 줄 지 알 게 될 것 입 니 다. 이것 은 무엇 을 설명 하 는 것 입 니까?
대상 을 향 한 생각 으로 이해한다 면 영업 사원 은 이곳 에서 공장 의 역할 을 맡 았 고, 그 는 당신 의 요구 에 따라 당신 이 필요 로 하 는 식품 대상 으로 돌아 가 는 일 을 맡 았 다.
이 점 이 단순 공장 모델 의 의도 다.
 

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            Operation oper;
            oper = OperationFactory.createOperate("+");
            oper.NumberA = 1;
            oper.NumberB = 2;
            double result = oper.GetResult();
            Console.Write(result+"
");
        }
    }
    public class Operation
    {
        private Double _numberA = 0;
        private Double _numberB = 0;
        public double NumberA
        {
            get
            {
                return _numberA;
            }
            set
            {
                _numberA = value;
            }
        }
        public double NumberB
        {
            get
            {
                return _numberB;
            }
            set
            {
                _numberB = value;
            }
        }
        public virtual double GetResult()
        {
            double result = 0;
            return result;
        }
    }
    class OperationAdd : Operation
    {
        public override double GetResult()
        {
            double result = 0;
            result = NumberA + NumberB;
            return result;
        }
    }
    class OperationSub : Operation
    {
        public override double GetResult()
        {
            double result = 0;
            result = NumberA - NumberB;
            return result;
        }
    }
    class OperationMul : Operation
    {
        public override double GetResult()
        {
            double result = 0;
            result = NumberA * NumberB;
            return result;
        }
    }
    class OperationDiv : Operation
    {
        public override double GetResult()
        {
            double result = 0;
            if (NumberB == 0)
            {
                throw new Exception("     0");
            }
            result = NumberA / NumberB;
            return result;
        }
    }
    public class OperationFactory
    {
        public static Operation createOperate(string operate)
        {
            Operation oper = null;
            switch (operate)
            {
                case "+":
                    oper = new OperationAdd();
                    break;
                case "-":
                    oper = new OperationSub();
                    break;
                case "*":
                    oper = new OperationMul();
                    break;
                case "/":
                    oper = new OperationDiv();
                    break;
            }
            return oper;
        }
    }
}

덧셈 연산 을 수정 하려 면 Operation Add 만 수정 하면 됩 니 다. 만약 에 우리 가 각종 복잡 한 연산 을 증가 해 야 합 니 다. 예 를 들 어 평 방 근, 큐 브 근, 자연 대수 등 우 리 는 해당 하 는 연산 자 류 를 증가 하고 switch 에서 가 지 를 증가 하면 됩 니 다. 인터페이스 를 수정 하려 면 인터페이스의 코드 와 연산 류 만 수정 하면 됩 니 다.
여기 서 다 형, 즉 자 류 는 아버지 류 로 나타 나 지만 자신의 방식 으로 이 루어 지 는 것 이다. 
여기 가 바로 가감 승제 류 가 연산 부류 의 신분 으로 나타 나 지만 각 하위 클래스 가 GetResult () 를 실현 하 는 방법 은 각각 다르다. 이렇게 하면 인터페이스 코드 가 구체 적 인 실례 를 만 들 지 않 고 소나무 결합의 목적 을 달성 할 수 있다.