디자인 모델 6 대 원칙 - 개방 폐쇄 원칙 (OCP)

무엇이 개폐 원칙 입 니까?
      정의: 소프트웨어 실체 (클래스, 모듈, 함수 등) 는 확장 할 수 있 지만 수정 할 수 없습니다.
      개폐 원칙 은 주로 두 가지 측면 에 나타난다.
      1. 확장 개방 은 새로운 수요 나 변화 가 있 을 때 기 존 코드 를 확장 하여 새로운 상황 에 적응 할 수 있 음 을 의미 합 니 다.
    2. 수정 에 대해 폐쇄 적 인 것 은 류 가 디자인 이 완성 되면 독립 적 으로 일 을 할 수 있 고 류 에 대해 어떠한 수정 도 하지 않 는 다 는 것 을 의미한다.
    
   개폐 원칙 은 어떻게 사용 합 니까?
    개방 폐쇄 를 실현 하 는 핵심 사상 은 추상 프로 그래 밍 이지 구체 적 인 프로 그래 밍 이 아니다. 추상 이 상대 적 으로 안정 적 이기 때문이다.종 류 를 고정된 추상 에 의존 하 게 하기 때문에 수정 에 대해 폐쇄 적 인 것 이다.한편, 대상 을 대상 으로 하 는 계승 과 다 형 체 제 를 통 해 추상 체 에 대한 계승 을 실현 할 수 있 고 그 방법 을 복사 하여 고유 행 위 를 바 꾸 고 새로운 확장 방법 을 실현 할 수 있 기 때문에 확장 에 있어 개방 적 이다.     이 원칙 을 위반 하 는 유형 에 대해 서 는 재 구성 을 통 해 개선 해 야 한다.실현 에 자주 사용 되 는 디자인 모델 은 주로 Template Method 모델 과 Strategy 모델 이 있다.한편, 포장 변 화 는 이 원칙 을 실현 하 는 중요 한 수단 으로 자주 변화 하 는 상 태 를 하나의 유형 으로 포장 하 는 것 이다.
      은행 업무원 을 예 로 들다 ：
      OCP 디자인 이 구현 되 지 않 은:  

public class BankProcess
    {
        public void Deposite(){}   //  
        public void Withdraw(){}   //  
        public void Transfer(){}   //  
    }

    public class BankStaff
    {
        private BankProcess bankpro = new BankProcess();
        public void BankHandle(Client client)
        {
            switch (client .Type)
            {
                case "deposite":      //  
                    bankpro.Deposite();
                    break;
                case "withdraw":      //  
                    bankpro.Withdraw();
                    break;
                case "transfer":      //  
                    bankpro.Transfer();
                    break;
            }
        }
    }

이런 디자인 은 분명히 문제 가 존재 한다. 현재 디자인 에서 저금, 인출 과 이체 세 가지 기능 만 있다. 앞으로 업무 가 증가 하면 예 를 들 어 구 매 신청 기금 기능, 재 태 크 기능 등 을 추가 하면 반드시 Bankprocess 업무 유형 을 수정 해 야 한다.우 리 는 상술 한 설 계 를 분석 해 보면 업 무 를 한 가지 유형 에 봉인 해 서 는 안 되 고 단일 직책 원칙 을 위반 해 서 는 안 되 며 새로운 수요 가 발생 하면 기 존 코드 를 수정 해 야 하 는 것 은 개방 폐쇄 원칙 을 위반 한 다 는 것 을 알 수 있다.
    어떻게 해야만 결합 도와 유연성 을 동시에 얻 을 수 있 습 니까? 
    그것 은 추상 적 인 것 이다. 업무 기능 을 인터페이스 로 추상 화하 고 업무원 이 고정된 추상 에 의존 할 때 수정 은 폐쇄 적 인 것 이 고 계승 과 다 중 계승 을 통 해 추상 체 에서 새로운 실현 을 확대 하 는 것 이 바로 확장 에 대한 개방 이다.
    다음은 OCP 에 맞 는 디자인 입 니 다.  

//            
    public interface IBankProcess
    {
        void Process();
    }
    public class DeposiProcess:IBankProcess
    {
        public void Process()         //      
        {
            Console.WriteLine("Process Deposit");
        }
    }
    public class WithDrawProcess:IBankProcess
    {
        public void Process()        //      
        {
            Console.WriteLine("Process WithDraw");
        }
    }
    public class TransferProcess:IBankProcess
    {
        public void Process()        //      
        {
            Console .WriteLine ("Process Transfer")；
        }
    }
    public class BankStaff
    {
        private IBankProcess  bankpro = null ;
        public void BankHandle(Client client)
        {
            switch (client .Type)
            {
                case "Deposite":      //  
                    userProc =new WithDrawUser();
                    break;
                case "WithDraw":      //  
                    userProc =new WithDrawUser();
                    break;
                case "Transfer":      //  
                    userProc =new WithDrawUser();
                    break;
            }
            userProc.Process();
        }
    }

이렇게 하면 업무 가 변 경 될 때 대응 하 는 업무 실현 류 만 수정 하면 되 고 다른 무관 한 업 무 는 수정 할 필요 가 없다.업무 가 늘 어 나 면 업무 의 실현 만 늘 리 면 된다.