답변:
이것은 아마도 설명하기 가장 견고한 원칙 중 가장 어려운 것입니다. 나 해보자. 완벽하게 작동하고 버그가없는 송장 클래스를 작성했다고 가정하십시오. 송장 PDF를 작성합니다.
그런 다음 누군가가 링크가 포함 된 HTML 송장을 원한다고 말합니다. 이 요청을 충족시키기 위해 송장의 코드를 변경하지 마십시오. 대신 다른 클래스 인 HTMLInvoice를 만들어 원하는대로 만듭니다. 상속을 활용하여 HTMLInvoice에 많은 중복 코드를 작성할 필요가 없습니다.
이전 송장을 사용하던 이전 코드는 손상되거나 실제로 영향을받지 않습니다. 새 코드는 HTMLInvoice를 사용할 수 있습니다. ( 단단한 L 인 Liskov Substitutability 도 수행하는 경우 인보이스 인스턴스를 기대하는 기존 코드에 HTMLInvoice 인스턴스를 제공 할 수 있습니다.) 누구나 행복하게 살아갑니다.
송장은 수정이 마감되고 확장이 열립니다. 그리고 이것이 작동하려면 송장을 올바르게 작성해야합니다.
ObjectMentor에서 Bob 아저씨의 친구들에 의한 공개 폐쇄 원칙 기사 를 읽었 습니까? 나는 그것이 더 나은 설명 중 하나라고 생각합니다.
객체 지향 디자인과 관련된 많은 휴리스틱이 있습니다. 예를 들어, "모든 구성원 변수는 개인용이어야합니다"또는 "전역 변수는 사용하지 않아야합니다"또는 "RTTI (런타임 유형 식별) 사용은 위험합니다". 이러한 휴리스틱의 소스는 무엇입니까? 무엇이 사실입니까? 그들은 항상 사실입니까? 이 칼럼에서는 이러한 휴리스틱의 기초가되는 디자인 원칙 인 개방형 원칙을 조사합니다.
Ivar Jacobson은 다음과 같이 말했습니다.“모든 시스템은 수명주기 동안 변경됩니다. 첫 번째 버전보다 오래 지속될 것으로 예상되는 시스템을 개발할 때이 점을 염두에 두어야합니다.”변화에 안정적이고 첫 번째 버전보다 오래 지속되는 디자인을 어떻게 만들 수 있습니까? 베르트랑 메이어 (Bertrand Meyer)는 1988 년 그가 지금 유명한 공개 폐쇄 원칙을 만들었을 때부터 우리에게 지침을주었습니다. 그를 역어 :
소프트웨어 엔티티 (클래스, 모듈, 기능 등)는 연장을 위해 열어야하지만 수정을 위해 닫혀 있어야합니다.
프로그램을 한 번 변경하면 종속 모듈이 연속적으로 변경 될 때 해당 프로그램은 "나쁜"디자인과 관련하여 원하지 않는 속성을 나타냅니다. 프로그램은 깨지기 쉽고 단단하며 예측할 수 없으며 재사용 할 수 없게됩니다. 공개 폐쇄 원칙은이를 매우 간단하게 공격합니다. 절대 변하지 않는 모듈을 설계해야한다고 말합니다 . 요구 사항이 변경되면 이미 작동하는 이전 코드를 변경하지 않고 새 코드를 추가하여 해당 모듈의 동작을 확장합니다.
기술
공개 폐쇄 원칙을 따르는 모듈에는 두 가지 주요 속성이 있습니다.
- 그것들은“확장을위한 개방”입니다.
이는 모듈의 동작이 확장 될 수 있음을 의미합니다. 애플리케이션의 요구 사항이 변경되거나 새로운 애플리케이션의 요구를 충족시키기 위해 모듈이 새롭고 다양한 방식으로 작동하도록 할 수 있습니다.- "수정 마감"입니다.
그러한 모듈의 소스 코드가 위배됩니다. 아무도 소스 코드를 변경할 수 없습니다.이 두 속성은 서로 상충되는 것 같습니다. 모듈의 동작을 확장하는 일반적인 방법은 해당 모듈을 변경하는 것입니다. 변경할 수없는 모듈은 일반적으로 고정 된 동작을하는 것으로 생각됩니다. 이 두 가지 반대되는 속성을 어떻게 해결할 수 있습니까?
추상화가 핵심이다 ...
Kate Gregory 의 대답 은 매우 좋지만 기존 Invoice클래스 의 상대적으로 작은 변화로 새로운 요구 사항을 충족시킬 수있는 다른 상황을 고려하십시오 . 예를 들어, 새 필드를 송장 PDF에 추가해야한다고 가정합니다. OCP에 따르면 몇 줄의 코드를 변경하여 기존 구현에 새 필드를 추가 할 수있는 경우에도 새 서브 클래스를 작성해야합니다.
내 이해에 따르면, OCP는 80 년대와 90 년대 초의 현실을 반영합니다. 프로젝트는 종종 버전 제어를 사용하지 않았고, 자동 회귀 테스트 나 정교한 리팩토링 도구의 이점이 훨씬 적었습니다. OCP는 수동으로 테스트하여 프로덕션 환경에 넣은 코드를 깨뜨릴 위험을 피하기위한 시도였습니다. 오늘날에는 작동중인 소프트웨어 (버전 제어 시스템, TDD 및 자동화 된 테스트, 리팩토링 도구)가 손상 될 위험을 관리하는 더 좋은 방법이 있습니다.
개인적으로 저는이 원리를 소금 한 덩어리로 가져와야한다고 생각합니다. 코드는 유기적이며 시간이 지남에 따라 비즈니스 요구에 따라 비즈니스가 변경되고 코드가 변경됩니다.
추상화가 핵심이라는 사실을 이해하기가 매우 어렵다는 것을 알게되었습니다. 추상화가 원래 잘못 되었다면 어떻게 될까요? 비즈니스 기능이 크게 변경된 경우 어떻게해야합니까?
이 원칙은 본질적으로 디자인의 원래 의도와 행동이 절대 변하지 않도록 보장합니다. 퍼블릭 API를 가지고 있고 클라이언트가 새로운 릴리스 및 다른 일부 사례를 따라 잡는 데 어려움이있는 사람들에게 효과적 일 수 있습니다. 그러나 회사가 모든 코드를 소유하고 있다면이 원칙에 도전합니다.
코드를 잘 테스트하면 코드 기반 리팩토링이 쉬워집니다. 그것은 물건을 잘못 얻는 것이 괜찮다는 것을 의미합니다. 테스트는 더 나은 디자인으로 안내하는 데 도움이됩니다.
테스트가 없다면이 원칙은 건전합니다.