Antigravity Agent
3.0 KiB
3.0 KiB
Open/Closed Principle (개방-폐쇄 원칙)
📌 Brief Summary
개방-폐쇄 원칙(Open/Closed Principle)은 기존의 코드를 수정하지 않고도 시스템의 기능을 확장할 수 있도록 하는 소프트웨어 설계 원칙입니다 [1, 2]. 주로 복잡한 분기를 가진 조건문을 다형성(Polymorphism)으로 대체하는 리팩토링 기법을 통해 구현됩니다 [1, 2]. 이 원칙을 준수하면 새로운 사례가 추가될 때 기존 로직을 수정하는 대신 새로운 클래스를 추가하는 방식으로 아키텍처 변경을 관리할 수 있습니다 [1-3].
📖 Core 소스 Content
- 조건문을 다형성으로 대체 (Replace Conditional with Polymorphism): 개방-폐쇄 원칙은 복잡한
switch문이나 여러 갈래의 조건문을 객체지향의 상속 구조와 동적 바인딩으로 해결할 때 준수됩니다 [1, 2]. - 동작 방식: 다양하게 변화하는 동작을 위한 인터페이스나 기본 클래스(base class)를 생성한 뒤, 각 조건 분기에 해당하는 구체적인 클래스(concrete class)를 구현합니다 [1]. 이후 기존의 조건부 로직을 다형성을 활용한 다형성 메서드 호출로 대체합니다 [1].
- 유지보수 및 테스트 용이성 확보: 새로운 타입이나 사례가 추가될 때, 기존의 논리 구조에 손을 대는(surgery) 대신 완전히 새로운 클래스를 작성하기만 하면 됩니다 [2, 3]. 각 행동이 클래스 단위로 격리되므로, 각 구현 클래스를 독립적으로 테스트하기가 매우 수월해집니다 [1, 3].
⚖️ Trade-offs & Caveats
- 사전 구조화 요구: 이 원칙을 따르기 위해 다형성을 도입하려면, 우선적으로 적절한 상속 구조가 마련되어 있어야 합니다 [4]. 이를 위해 '타입 코드를 하위 클래스로 바꾸기(Replace Type Code with Subclasses)'나 '상태/전략 패턴으로 바꾸기(Replace Type Code with State/Strategy)'와 같은 리팩토링이 선행되어야 하는 부담이 있습니다 [4].
- 과도한 엔지니어링(Overkill) 위험: 동일한 조건문이 프로그램 여러 곳에 흩어져 있을 때는 다형성 도입이 큰 이점을 제공하지만, 단일 메서드에만 영향을 미치는 소수의 조건문이며 향후 변경될 것으로 예상되지 않는다면 다형성을 도입하는 것은 과도한 엔지니어링이 될 수 있습니다 [5, 6]. 이 경우 '매개변수를 명시적 메서드로 바꾸기(Replace Parameter with Explicit Methods)' 등 더 단순한 접근이 적절할 수 있습니다 [5].
- 객체 수명 주기 제약: 객체 생성 이후에 객체의 타입(Type Code)이 변할 수 있는 상황이라면 단순한 하위 클래스화(subclassing)를 사용할 수 없습니다 [4]. 이 경우에는 상대적으로 더 복잡한 상태나 전략 패턴(State/Strategy Pattern)을 필수적으로 도입해야 하는 제약이 따릅니다 [4].
Last updated: 2026-05-03