정의 : 클래스, 모듈 및 기능과 같은 소프트웨어 엔티티는 확장에 열려야하고 수정으로 닫아야합니다.
문제의 기원 : 소프트웨어의 수명주기 동안, 변경, 업그레이드 및 유지 보수로 인해 소프트웨어의 원래 코드를 수정 해야하는 경우, 오류는 이전 코드에 도입 될 수 있으며 전체 기능을 리팩터링하도록 강요 할 수 있으며 원래 코드를 다시 테스트해야합니다.
솔루션 : 소프트웨어가 변경되어야 할 때 기존 코드를 수정하지 않고 소프트웨어 엔티티의 동작을 확장하여 변경 사항을 달성하십시오.
개방 및 폐쇄의 원리는 객체 지향 디자인에서 가장 기본적인 설계 원칙으로, 안정적이고 유연한 시스템을 설정하는 방법을 안내합니다. 개방 및 폐쇄의 원리는 디자인 패턴의 6 가지 원칙에 대한 가장 모호한 정의 일 수 있습니다. 그것은 우리에게 수정을 열고 닫으라고 말하지만, 어떻게 우리는 어떻게 열리고 닫히고 명확하게 말하지 않을 수 있습니까? 과거에 누군가가 나에게 "디자인 할 때 개방 및 폐쇄의 원리를 준수해야한다"고 말하면, 나는 그가 아무 말도하지 않았다고 생각했지만 그가 모든 것을 말한 것처럼 보였다. 개방 및 폐쇄의 원리는 너무 비어 있기 때문입니다.
디자인 패턴에 대한 많은 기사를 신중하게 생각하고 읽은 후 마침내 개방 및 폐쇄의 원리에 대해 약간의 이해를 얻었습니다. 실제로, 우리는 디자인 패턴의 처음 5 가지 원칙을 따릅니다. 23 개의 디자인 패턴을 사용하는 목적은 개방 및 마감 원리를 따르는 것입니다. 다시 말해서, 처음 5 개의 원칙을 준수하는 한, 설계된 소프트웨어는 자연스럽게 개방 및 폐쇄 원칙을 준수합니다. 이 오프닝 및 마감 원리는 처음 5 개의 원칙의 준수 정도의 "평균 점수"와 비슷합니다. 이전 5 개의 원칙이 잘 따랐다면 평균 점수는 자연스럽게 높아 지므로 소프트웨어 설계 개방 및 마감 원리가 잘 따릅니다. 이전 다섯 가지 원칙이 준수되지 않으면 개방 및 마감 원칙이 준수되지 않음을 의미합니다.
실제로, 저자는 개방 및 폐쇄의 원리가 의미를 표현하는 것 이상이라고 생각합니다. 추상화로 프레임 워크를 구축하고 구현으로 세부 사항을 확장합니다. 추상화가 합리적 인 한, 추상화의 유연성과 광범위한 적응성으로 인해 소프트웨어 아키텍처의 안정성을 기본적으로 유지할 수 있습니다. 소프트웨어의 변수 세부 사항의 경우 Abstract에서 파생 된 구현 클래스를 사용합니다. 소프트웨어가 변경되어야 할 때 확장 요구에 따라 구현 클래스를 다시 실현하면됩니다. 물론, 전제는 우리의 추상화가 합리적이어야하며 우리는 수요의 변화에 미래 지향적이고 예측해야한다는 것입니다.
개방 및 폐쇄 원칙의 정의에서 소프트웨어 엔티티는 소프트웨어 모듈, 여러 클래스로 구성된 로컬 구조 또는 독립 클래스를 참조 할 수 있습니다.
모든 소프트웨어는 중요한 문제에 직면해야합니다. 즉, 그들의 요구는 시간이 지남에 따라 변할 것입니다. 소프트웨어 시스템이 새로운 요구에 직면 해야하는 경우 시스템 설계 프레임 워크가 안정되도록 최선을 다해야합니다. 소프트웨어 디자인이 개방 및 폐쇄 원리를 준수하는 경우 시스템을 확장하는 것이 매우 편리 할 수 있으며 확장 할 때 기존 코드를 수정할 필요가 없으므로 소프트웨어 시스템이 적응성과 유연성을 갖는 동안 안정성과 연속성이 향상됩니다. 소프트웨어 규모가 커지면 소프트웨어 수명이 길어지고 소프트웨어 유지 관리 비용이 점점 높아지고 개방 및 마감 원리를 충족하는 소프트웨어 시스템을 설계하는 것이 점점 더 중요 해지고 있습니다.
개방 및 폐쇄의 원리를 충족시키기 위해서는 시스템을 추상적으로 설계해야하며 추상화는 개방 및 폐쇄 원리의 핵심입니다. Java 및 C#과 같은 프로그래밍 언어에서는 시스템에 대해 비교적 안정적인 추상화 계층을 정의 할 수 있으며, 다른 구현 동작을 특정 구현 계층으로 이동하여 완료 할 수 있습니다. 많은 객체 지향 프로그래밍 언어에서, 인터페이스 및 추상 클래스와 같은 메커니즘이 제공되며,이를 통해 시스템의 추상화 계층을 구체적인 클래스를 통해 확장 할 수 있습니다. 시스템의 동작을 수정 해야하는 경우 추상화 계층을 변경할 필요가 없습니다. 기존 코드를 수정하지 않고 시스템의 기능을 확장하고 개방 및 폐쇄 원리의 요구 사항을 충족하기 위해 새로운 비즈니스 기능을 구현하기 위해 새로운 콘크리트 클래스를 추가하면됩니다.
Sunny Software에서 개발 한 CRM 시스템은 파이 차트 및 막대 차트와 같은 다양한 유형의 차트를 표시 할 수 있습니다. 여러 차트 디스플레이 방법을 지원하기 위해 원래 설계 계획은 다음 그림에 나와 있습니다.
다음 코드 스 니펫은 ChartDisplay 클래스의 display () 메소드에 있습니다.
...... if (type.equals ( "pie")) {piechart 차트 = new piechart (); Chart.Display (); } else if (type.equals ( "bar")) {barchart 차트 = new Barchart (); Chart.Display (); } ...... 이 코드에서 Linechart와 같은 새 차트 클래스를 추가 해야하는 경우 ChartDisplay 클래스의 Display () 메소드의 소스 코드를 수정하고 개방 및 폐쇄 원리를 위반하는 새로운 판단 로직을 추가해야합니다.
이 시스템은 이제 개방 및 폐쇄의 원리를 준수하도록 재구성되었습니다.
이 예에서는 각 차트 클래스가 ChartDisplay 클래스의 display () 메소드에서 프로그래밍되므로 새 차트 클래스를 추가하면 소스 코드를 수정해야합니다. 새로운 차트 클래스를 추가 할 때 소스 코드를 수정할 필요가 없으므로 개방 및 폐쇄 원리를 만족시킬 필요가 없습니다. 특정 방법은 다음과 같습니다.
(1) 추상 차트 클래스 AbstractChart를 추가하고 다양한 콘크리트 차트 클래스를 하위 클래스로 사용하십시오.
(2) ChartDisplay 클래스는 추상 차트 클래스를 위해 프로그래밍되며 클라이언트는 사용할 특정 차트를 결정합니다.
재구성 후 구조는 아래 그림에 나와 있습니다.
그림 2에서는 추상 차트 클래스 AbstractChart를 소개하고 ChartDisplay는 Abstract Chart 클래스를 위해 프로그래밍되며 클라이언트는 setchart () 메소드를 통해 인스턴스화 된 특정 차트 객체를 설정합니다. ChartDisplay의 display () 메소드에서 차트 객체의 display () 메소드가 호출되어 차트를 표시합니다. Linechart와 같은 새 차트를 추가 해야하는 경우 Linechart를 AbstractChart의 서브 클래스로만 사용하고 기존 클래스 라이브러리의 소스 코드를 수정하지 않고 클라이언트의 ChartDisplay에 Linechart 객체를 주입하면됩니다.
참고 : XML 및 속성과 같은 형식의 구성 파일은 일반 텍스트 파일이므로 컴파일없이 VI 편집기 또는 메모장을 통해 직접 편집 할 수 있습니다. 소프트웨어 개발에서 구성 파일의 수정은 일반적으로 시스템 소스 코드의 수정으로 간주되지 않습니다. 시스템이 확장 될 때 구성 파일을 수정하고 원래 Java 코드 또는 C# 코드가 수정되지 않은 경우 시스템은 개방 및 폐쇄 원리를 준수하는 시스템으로 간주 될 수 있습니다.