위키
포럼
도구
바뀐글
랜덤

"개방-폐쇄 원칙"의 두 판 사이의 차이

 
4번째 줄: 4번째 줄:
* [[SOLID]]의 하나
* [[SOLID]]의 하나
* 코드를 변경하지 않고 확장할 수 있게 설계하자. ★
* 코드를 변경하지 않고 확장할 수 있게 설계하자. ★
* 확장은 자유롭게 하되, 기존 코드의 수정은 최소화하자.
* 기존 코드를 수정하지 말고 [[상속]] 또는 [[객체 컴포지션|컴포지션]]을 통해 확장할 수 있게 하자.  
* 기존 코드를 수정하지 말고 [[상속]] 또는 [[객체 컴포지션|컴포지션]]을 통해 확장할 수 있게 하자.  
* 확장은 자유롭게 하되, 기존 코드의 수정은 최소화하자.
* "소프트웨어 개체<ref>클래스, 모듈, 함수 등</ref>는 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다."
* "소프트웨어 개체<ref>클래스, 모듈, 함수 등</ref>는 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다."
* 필요에 따라 기존 인터페이스/클래스를 상속 받아 확장하는 것은 좋다. 다만 잘 돌아가던 모듈 그 자체를 수정하는 일은 최소화하자.
* 필요에 따라 기존 인터페이스/클래스를 상속 받아 확장하는 것은 좋다. 다만 잘 돌아가던 모듈 그 자체를 수정하는 일은 최소화하자.

2022년 7월 20일 (수) 08:38 기준 최신판

1 개요[ | ]

open–closed principle, open/closed principle (OCP)
개방-폐쇄 원칙, 개방 폐쇄 원칙
  • SOLID의 하나
  • 코드를 변경하지 않고 확장할 수 있게 설계하자. ★
  • 확장은 자유롭게 하되, 기존 코드의 수정은 최소화하자.
  • 기존 코드를 수정하지 말고 상속 또는 컴포지션을 통해 확장할 수 있게 하자.
  • "소프트웨어 개체[1]는 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다."
  • 필요에 따라 기존 인터페이스/클래스를 상속 받아 확장하는 것은 좋다. 다만 잘 돌아가던 모듈 그 자체를 수정하는 일은 최소화하자.
  • 추상화 + 캡슐화를 통해 가능하다.
(추상화) 잘 바뀌지 않는 공통 부분을 상위 클래스로 고정시킨다.
(캡슐화) private으로 외부와 단절. 단 외부에서 조작해야 하는 부분은 public으로 열어둔다.
  • OCP가 잘 적용되면 원래 모듈의 변경을 최소화할 수 있다.
  • 물론 새 모듈을 덧붙이는 작업은 필요하다. 전체 구조는 유지되므로 유지보수가 용이하다.
  • OCP를 위반하면 다른 OOP 설계원칙도 위반하게 되는 경우가 많다.
  • 변경(확장) 대상과 불변 대상을 잘 구분해야 한다. (필요시 클래스 분할)
  • 클래스간의 공통점을 추출하여 인터페이스를 만들어 활용하자. (필요시 전략 패턴 활용)

2 같이 보기[ | ]

3 참고[ | ]

  1. ↑ 클래스, 모듈, 함수 등
원본 주소 "https://zetawiki.com/w/index.php?title=개방-폐쇄_원칙&oldid=825060"
문서 댓글 ({{ doc_comments.length }})
{{ comment.name }} {{ comment.created | snstime }}