디자인 모델 6 대 원칙 (2): 개방 폐쇄 원칙

링크 열기
폐쇄 원칙 개발 (개방 형 원리 OCP)
Software entities(classes,modules,functions etc) should open for extension ,but close for modification.
   무슨 뜻 이 죠?
   개방 폐쇄 원칙 이란 소프트웨어 실체 가 확장 개발 을 하고 수정 을 폐쇄 해 야 한 다 는 것 이다.개방 폐쇄 원칙 은 모든 대상 지향 원칙 의 핵심 이다.소프트웨어 디자인 자체 가 추구 하 는 목 표 는 패 키 징 변화 이 고 결합 을 낮 추 는 것 이다. 개방 폐쇄 원칙 은 바로 이 목표 에 대한 가장 직접적인 표현 이다.
   개방 폐쇄 원칙 은 주로 두 가지 측면 에 나타난다.
   확장 개방 은 새로운 수요 나 변화 가 있 을 때 기 존 코드 를 확장 하여 새로운 상황 에 적응 할 수 있 음 을 의미 합 니 다.
   수정 이 폐쇄 된 것 은 류 가 일단 설계 가 완성 되면 독립 적 으로 일 을 할 수 있 고 류 에 대해 어떠한 수정 도 하지 않 는 다 는 것 을 의미한다.
 
왜 개방 폐쇄 원칙 을 써 야 합 니까?
소프트웨어 수 요 는 항상 변화 한다. 세계 에서 변 하지 않 는 소프트웨어 가 하나 도 없 기 때문에 소프트웨어 설계 자 에 게 는 기 존의 시스템 을 수정 하지 않 아 도 되 는 상황 에서 유연 한 시스템 확장 을 실현 해 야 한다.
 
어떻게 확장 개방, 수정 폐쇄 를 할 수 있 습 니까?
      개방 폐쇄 를 실현 하 는 핵심 사상 은 추상 프로 그래 밍 이지 구체 적 인 프로 그래 밍 이 아니다. 추상 이 상대 적 으로 안정 적 이기 때문이다.종 류 를 고정된 추상 에 의존 하 게 하기 때문에 수정 에 대해 폐쇄 적 인 것 이다.한편, 대상 을 대상 으로 하 는 계승 과 다 형 체 제 를 통 해 추상 체 에 대한 계승 을 실현 할 수 있 고 그 방법 을 복사 하여 고유 행 위 를 바 꾸 고 새로운 확장 방법 을 실현 할 수 있 기 때문에 확장 에 있어 개방 적 이다.
      이 원칙 을 위반 하 는 유형 에 대해 서 는 재 구성 을 통 해 개선 해 야 한다.실현 에 자주 사용 되 는 디자인 모델 은 주로 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 DepositProcess : 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 "Deposit":

                    userProc = new DepositUser();

                    break;

                    //  

                case "Transfer":

                    userProc = new TransferUser();

                    break;

                    //  

                case "WithDraw":

                    userProc = new WithDrawUser();

                    break;

            }

            userProc.Process();

        }

    }

이렇게 하면 업무 가 변 경 될 때 대응 하 는 업무 실현 류 만 수정 하면 되 고 다른 무관 한 업 무 는 수정 할 필요 가 없다.업무 가 늘 어 나 면 업무 의 실현 만 늘 리 면 된다.
 
디자인 제안:
개방 폐쇄 원칙 은 가장 중요 한 디자인 원칙 으로 Liskov 교체 원칙 과 합성 / 중합 재 활용 원칙 은 개방 폐쇄 원칙 에 보증 을 제공한다.
Template Method 모델 과 Strategy 모델 을 재 구성 하여 수정 에 대한 폐쇄 를 실현 하고 개방 적 인 디자인 방향 을 확대 할 수 있 습 니 다.
포장 변 화 는 개방 폐쇄 원칙 을 실현 하 는 중요 한 수단 으로 자주 변화 하 는 상태 에 대해 일반적으로 이 를 추상 적 인 것 으로 봉 한다. 예 를 들 어 은행 업무 에서 IBankProcess 인터페이스 등 이다.
추상 의 남용 을 거부 하고 자주 변화 하 는 부분 만 추상적으로 한다.