개방-폐쇄 원칙
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
개방-폐쇄 원칙은 소프트웨어 설계 원칙으로, 모듈은 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다는 내용을 담고 있다. 1988년 버트란드 마이어에 의해 처음 제시되었으며, 로버트 C. 마틴에 의해 추상화된 인터페이스 사용을 강조하는 방향으로 재정의되었다. 핵심 원리는 모듈의 동작을 확장할 수 있도록 열어두면서, 소스 코드나 바이너리 코드를 수정하지 않고도 기능을 변경할 수 있도록 하는 것이다. 객체 지향 프로그래밍의 핵심 원칙 중 하나로, 유연성, 재사용성, 유지보수성을 높이는 데 기여한다.
더 읽어볼만한 페이지
- 프로그래밍 원칙 - 블랙박스
블랙 박스는 자극 입력과 출력 반응의 관점에서 시스템을 추상화하여 외부적으로 관찰하는 이론으로, 전자 회로 이론, 사이버네틱스, 시스템 이론 등 다양한 분야에서 활용되며 예측 모델 구축 및 유효성 검증, 그리고 항공기 비행 기록 장치나 함수 교육 도구 등 실생활에도 응용된다. - 프로그래밍 원칙 - 정보 은닉
정보 은닉은 소프트웨어 설계에서 모듈 내부 구현을 숨기고 정의된 인터페이스를 통해서만 상호 작용하도록 하여 모듈 독립성을 높이고 시스템 복잡성을 관리하는 데 중요한 기법으로, 객체 지향 프로그래밍의 캡슐화와 관련된다. - 소프트웨어 설계 - 구조적 분석
구조적 분석은 1960년대에서 1980년대 소프트웨어 개발의 복잡성을 해결하기 위해 개발된 기법으로, 다이어그램과 데이터 사전을 활용하여 시스템을 분석하고 설계했으며, 객체 지향 프로그래밍의 등장으로 활용도가 감소했다. - 소프트웨어 설계 - 지속적 배포
지속적 배포(CD)는 소프트웨어 릴리스 프로세스를 자동화하는 접근 방식이며, 배포 파이프라인을 통해 구현되고 시장 출시 시간 단축, 제품 품질 향상 등의 이점을 제공하지만 테스트 자동화 부족 등의 과제도 존재한다. - 소프트웨어 개발 철학 - 애자일 소프트웨어 개발
애자일 소프트웨어 개발은 1990년대에 등장하여 개인과 상호작용, 작동하는 소프트웨어, 고객과의 협력, 변화에 대한 대응을 핵심 가치로 삼고 적응형 계획과 반복적 실행을 통해 시장 출시 속도와 위험 완화를 추구하는 소프트웨어 개발 방법론이다. - 소프트웨어 개발 철학 - 유닉스 철학
유닉스 철학은 단순성, 모듈성, 재사용성을 중시하며, 한 가지 일을 잘하는 프로그램, 협력적인 프로그램, 텍스트 스트림 처리 프로그램을 지향하는 소프트웨어 설계 원칙으로, 현대 운영체제 및 소프트웨어 설계에 영향을 주지만 비판도 존재한다.
| 개방-폐쇄 원칙 | |
|---|---|
| 개방-폐쇄 원칙 | |
| 다른 이름 | 개방/폐쇄 원칙 |
| 영어 | Open/Closed Principle (OCP) |
| 유형 | 객체 지향 프로그래밍 원칙 |
| 설명 | 소프트웨어 개체(클래스, 모듈, 함수 등)는 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다. |
| 역사 | |
| 최초 언급 | 베르트랑 메이어 (객체 지향 소프트웨어 구축) (1988) |
| 공식화 | 로버트 C. 마틴 (2000) |
| 목표 | |
| 목표 | 변경 사항에 의해 기존 코드가 수정되지 않도록 하여 소프트웨어 유지 보수 및 확장을 용이하게 한다. |
| 장점 | |
| 장점 | 코드 재사용성 향상 안정성 향상 유지보수성 향상 |
| 적용 방법 | |
| 추상화 | 인터페이스나 추상 클래스를 사용하여 구현 세부 사항으로부터 분리한다. |
| 다형성 | 런타임에 객체의 실제 유형에 따라 동작이 달라지도록 한다. |
| 상속 | 기존 클래스를 확장하여 새로운 기능을 추가한다. |
| 컴포지션 | 객체를 조립하여 더 복잡한 기능을 만든다. |
2. 역사
소프트웨어 공학의 발전과 함께, 객체 지향 프로그래밍의 등장과 더불어 개방-폐쇄 원칙은 중요한 설계 원리로 자리 잡았다.
2. 1. 버트란드 마이어의 초기 정의 (1988)
버트란드 마이어는 1988년 자신의 저서 《객체 지향 소프트웨어 구축》에서 "개방-폐쇄 원칙"이라는 용어를 처음 사용한 것으로 알려져 있다.[2][1]마이어는 모듈이 확장을 위해 열려 있어야 한다고 정의했다. 예를 들어, 모듈에 포함된 데이터 구조에 필드를 추가하거나, 수행하는 함수 집합에 새로운 요소를 추가하는 것이 가능해야 한다. 또한, 모듈은 다른 모듈에서 사용할 수 있도록 닫혀 있어야 한다고 정의했다. 이는 모듈이 잘 정의되고 안정적인 인터페이스를 가지고 있다는 것을 의미한다.[7]
당시 마이어는 라이브러리에 필드나 함수를 추가하려면 해당 라이브러리에 의존하는 모든 프로그램을 변경해야 하는 문제가 있다고 보았다. 이 문제에 대한 마이어의 해결책은 객체 지향 상속(특히 구현 상속) 개념을 활용하는 것이었다.[1]
마이어는 클래스가 컴파일되어 라이브러리에 저장되고 기준선이 설정되어 클라이언트 클래스에서 사용될 수 있기 때문에 폐쇄되어 있다고 보았다. 하지만 새로운 클래스가 부모 클래스로 사용하여 새로운 기능을 추가할 수 있기 때문에 개방되어 있다고도 보았다. 즉, 후손 클래스를 정의할 때 원본을 변경하거나 클라이언트를 방해할 필요가 없도록 설계하는 것이 핵심이었다.
마이어는 부모 클래스에서 불변의 사양을 정의하고, 이를 상속하는 각 자손 클래스에서 구현을 수정하거나 확장해야 한다고 주장했다. 부모 클래스의 변수에는 부모 클래스 또는 각 자손 클래스의 인스턴스를 대입할 수 있으며, 클라이언트는 해당 부모 클래스 변수를 영구적으로 사용할 수 있고, 해당 변수에 자손 인스턴스가 대입되어도 영향을 받지 않도록 해야 한다.[8]
마이어의 원칙은 구체 메서드(시그니처 + 코드)의 구현 상속과 자식 클래스를 추가 정의해 나가는 깊은 상속을 기본으로 한다.
2. 2. 로버트 C. 마틴의 재정의 (1996)
1990년대 동안, 개방-폐쇄 원칙은 추상화된 인터페이스의 사용을 강조하는 방향으로 널리 재정의되었는데, 여기서 구현은 변경될 수 있으며, 여러 구현을 생성하고 서로 다형적으로 대체할 수 있다.마이어의 용법과는 대조적으로, 이 정의는 추상 기본 클래스로부터의 상속을 옹호한다. 인터페이스 명세는 상속을 통해 재사용될 수 있지만, 구현은 그럴 필요가 없다. 기존 인터페이스는 수정에 대해 닫혀 있으며, 새로운 구현은 최소한 해당 인터페이스를 구현해야 한다.
로버트 C. 마틴의 1996년 기사 "개방-폐쇄 원칙"[2]은 이러한 접근 방식을 취한 중요한 저작물 중 하나였다. 2001년, 크레이그 라르만은 개방-폐쇄 원칙을 앨리스테어 코크번이 제시한 '보호된 변동'이라는 패턴 및 데이비드 파나스의 ''정보 은닉''에 대한 논의와 관련시켰다.[3]
3. 핵심 원리
버트란드 마이어는 "개방-폐쇄 원칙"이라는 용어를 처음 사용한 것으로 여겨지며, 그의 1988년 저서 객체 지향 소프트웨어 구축(Object-Oriented Software Construction)에 이 원칙이 등장했다.[1]
개방-폐쇄 원칙의 핵심은 다음과 같다.
- 모듈은 확장을 위해 열려 있어야 한다. 즉, 데이터 구조에 필드를 추가하거나 함수 집합에 새로운 요소를 추가하는 것이 가능해야 한다.
- 모듈은 다른 모듈에서 사용할 수 있도록 닫혀 있어야 한다. 즉, 모듈은 잘 정의되고 안정적인 인터페이스를 가져야 한다.
마이어는 당시 라이브러리에 필드나 함수를 추가하려면 해당 라이브러리에 의존하는 모든 프로그램에 변경이 필요했던 문제를 지적했다. 그는 이 문제에 대한 해결책으로 객체 지향 상속, 특히 구현 상속을 제시했다.[1]
마이어에 따르면, 클래스는 컴파일되어 라이브러리에 저장되고 기준선이 설정되어 클라이언트 클래스에서 사용될 수 있기 때문에 닫혀 있다. 하지만 새로운 클래스가 부모 클래스를 상속받아 새로운 기능을 추가할 수 있기 때문에 열려 있기도 하다. 이렇게 하면 원본 코드를 변경하거나 클라이언트를 방해하지 않고도 기능을 확장할 수 있다.
1990년대에 들어서면서 개방-폐쇄 원칙은 추상화된 인터페이스를 사용하는 방식으로 재정의되었다. 이 방식에서는 구현은 변경될 수 있으며, 여러 구현을 생성하고 다형적으로 대체할 수 있다.
마이어의 방식과는 다르게, 이 정의는 추상 기본 클래스로부터의 상속을 옹호한다. 인터페이스 명세는 상속을 통해 재사용될 수 있지만, 구현은 그럴 필요가 없다. 기존 인터페이스는 수정에 대해 닫혀 있으며, 새로운 구현은 최소한 해당 인터페이스를 구현해야 한다.
로버트 C. 마틴의 1996년 기사 "개방-폐쇄 원칙"[2]은 이러한 접근 방식을 취한 중요한 저작물 중 하나였다. 2001년, 크레이그 라르만은 개방-폐쇄 원칙을 앨리스테어 코크번이 제시한 ''보호된 변동''이라는 패턴 및 데이비드 파나스의 ''정보 은닉''에 대한 논의와 관련시켰다.[3]
3. 1. 확장에 대해 열려 있음
모듈의 동작은 확장 가능해야 한다. 즉, 애플리케이션의 요구 사항이 변경될 때, 새로운 동작을 추가하여 모듈을 확장할 수 있어야 한다. 이는 모듈이 하는 일을 변경할 수 있다는 것을 의미한다.[2]버트란드 마이어는 "개방-폐쇄 원칙"이라는 용어를 처음 사용한 것으로 여겨지며,[2] 그의 1988년 저서 객체 지향 소프트웨어 구축(Object-Oriented Software Construction)에 등장했다.[1]
> * 모듈은 확장을 위해 여전히 사용 가능하다면 개방되었다고 말한다. 예를 들어, 포함된 데이터 구조에 필드를 추가하거나 수행하는 함수 집합에 새로운 요소를 추가하는 것이 가능해야 한다.
마이어가 글을 쓸 당시에는, 라이브러리에 필드나 함수를 추가하려면 필연적으로 해당 라이브러리에 의존하는 모든 프로그램에 변경이 필요했다. 이 문제에 대한 마이어의 해결책은 객체 지향 상속 (특히 구현 상속)의 개념에 의존했다.[1]
> 클래스는 컴파일되어 라이브러리에 저장되고, 기준선이 설정되며, 클라이언트 클래스에서 사용될 수 있기 때문에 폐쇄되어 있다. 하지만 새로운 클래스가 부모로 사용하여 새로운 기능을 추가할 수 있기 때문에 개방되어 있기도 하다. 후손 클래스가 정의될 때, 원본을 변경하거나 클라이언트를 방해할 필요가 없다.
1990년대 동안, 개방-폐쇄 원칙은 추상화된 인터페이스의 사용을 지칭하는 것으로 널리 재정의되었는데, 여기서 구현은 변경될 수 있으며, 여러 구현을 생성하고 서로 다형적으로 대체할 수 있다.
마이어의 용법과는 대조적으로, 이 정의는 추상 기본 클래스로부터의 상속을 옹호한다. 인터페이스 명세는 상속을 통해 재사용될 수 있지만, 구현은 그럴 필요가 없다. 기존 인터페이스는 수정에 대해 닫혀 있으며, 새로운 구현은 최소한 해당 인터페이스를 구현해야 한다.
로버트 C. 마틴의 1996년 기사 "개방-폐쇄 원칙"[2]은 이러한 접근 방식을 취한 중요한 저작물 중 하나였다. 2001년, 크레이그 라르만은 개방-폐쇄 원칙을 앨리스테어 코크번이 제시한 ''보호된 변동''이라는 패턴 및 데이비드 파나스의 ''정보 은닉''에 대한 논의와 관련시켰다.[3]
원래의 개방-폐쇄 원칙은 1988년 버트란드 마이어의 저서 『객체 지향 소프트웨어 구성』에서 제창되었다.[6]
- 확장이 가능하다면 해당 모듈은 개방되어 있다고 할 수 있다. 해당 모듈은 데이터 구조에 필드를 추가할 수 있으며, 함수의 집합에 새로운 것을 추가할 수 있어야 한다.
마이어는, 부모 클래스에서 불변의 사양을 정의하고, 이를 상속하는 각 자손 클래스에서 구현을 수정 또는 확장해야 한다고 했다. 부모 클래스의 변수에는 부모 클래스 또는 각 자손 클래스의 인스턴스가 대입된다. 클라이언트는 해당 부모 클래스 변수를 영구적으로 사용할 수 있으며, 해당 변수에 자손 인스턴스가 대입되어 있어도 지장을 받지 않는다.[8]
마이어의 원칙에서는, 구체 메서드(시그니처 + 코드)의 구현 상속(implementation inheritance)과 자식 클래스를 추가 정의해나가는 깊은 상속이 기본이 된다.
1990년대의 개방-폐쇄 원칙은 인터페이스의 런타임 서브타이핑을 중시하도록 의미가 바뀌어 갔다. Robert C. Martin영어의 1996년 논문 「The Open-Closed Principle」 등이 이를 접근하고 있다.
추상 메서드만으로 구성된 불변의 인터페이스를 정의하고, 이를 코드 구현하기 위한 형제 클래스를 다양하게 정의하여 런타임에서 인터페이스 변수에 각 형제 인스턴스를 대입하고 교환하여 런타임 다형성을 해야 한다고 했다.
마틴의 원칙에서는 추상 메서드(시그니처만)의 인터페이스 상속이 기본이 된다. 상속 관계는 인터페이스의 구현에 한정하고, 클래스의 상속은 억제하는 것이 기본이 된다.
2001년에 Craig Larman영어이 이 접근 방식을 GRASP의 보호적 변동(Protected Variations)과 관련지어 David Parnas영어의 Information hiding영어도 언급하고 있다.
3. 2. 변경에 대해 닫혀 있음
모듈의 소스 코드나 바이너리 코드를 수정하지 않아도 모듈의 기능을 확장하거나 변경할 수 있다. 이는 모듈의 실행 가능한 바이너리 형태나 링크 가능한 라이브러리(예: 윈도의 DLL이나 자바의 .jar)를 건드릴 필요가 없음을 의미한다.[2]4. 추상화를 통한 구현
객체 지향 프로그래밍 언어(JAVA, C++ 등)에서는 추상화를 통해 개방-폐쇄 원칙을 구현할 수 있다. 추상화는 고정되기는 해도 제한되지는 않은, 가능한 동작의 묶음을 표현한다. 모듈은 추상화를 조작할 수 있다. 이런 모듈은 고정된 추상화에 의존하기 때문에 수정에 대해 닫혀 있을 수 있고, 반대로 추상화의 새 파생 클래스를 만드는 것을 통해 확장도 가능하다.[2] 따라서 추상화는 개방-폐쇄 원칙의 핵심 요소이다.
5. 객체 지향 프로그래밍과의 관계
개방-폐쇄 원칙은 객체 지향 프로그래밍의 핵심 원칙 중 하나이다.[2] 이 원칙을 따르지 않아도 객체 지향 언어(Java, C++ 등) 구현이 불가능한 것은 아니지만, 이 원칙을 무시하면 객체 지향 프로그래밍의 가장 큰 장점인 유연성, 재사용성, 유지보수성을 얻기 어렵다. 따라서 객체 지향 프로그래밍 언어에서 개방-폐쇄 원칙은 기본적인 원칙으로 간주된다.
버트란드 마이어는 "개방-폐쇄 원칙"이라는 용어를 처음 사용한 것으로 여겨진다.[2] 그는 1988년 저서 객체 지향 소프트웨어 구축(Object-Oriented Software Construction)에서 이 원칙을 설명했다.[1]Object-Oriented Software Construction영어
참조
[1]
서적
Object-Oriented Software Construction
Prentice Hall
[2]
간행물
The Open-Closed Principle
https://docs.google.[...]
C++ Report
1996-01
[3]
논문
Protected Variation: The Importance of Being Closed
http://codecourse.so[...]
IEEE
2001-05
[4]
서적
Object-Oriented Software Construction
Prentice Hall
[5]
문서
Martin 1996
[6]
간행물
The Open-Closed Principle
https://docs.google.[...]
C++ Report
1996-01
[7]
서적
Object-oriented software construction
Prentice Hall
1988
[8]
서적
Object-oriented software construction
Prentice Hall
1988
[9]
논문
Protected Variation: The Importance of Being Closed
http://www.craiglarm[...]
2001-05
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com