OCP (Open/Cloesed Priciple; 개방-폐쇄 원칙)
소프트웨어 요소는 확장에는 열려있으나 변경에는 닫혀있어야 한다.
SRP의 연장선에 있는 원칙이라고 생각한다.
SRP에 맞게 하나의 책임을 가지고 있는 클래스를 확장하여 새로운 책임에 집중한 클래스를 만들 수 있다.
그렇게 되면 해당 클래스는 자신의 책임에 집중하고 다른 책임을 변경할 필요가 없다.
만약 변경이 일어날 수 있는 코드가 있다면 추상화를 통해 구현을 상속받는 클래스에 맡겨야 한다.
추상화한 코드로 인해 상위 클래스는 수정할 필요가 없고 하위 클래스는 구현을 통해 확장할 수 있다.
OCP 예시
이미지를 포함하고 있는 메모를 작성하는 안드로이드 코드이다.
메모를 작성할 때, 메모를 수정할 때 모두 이미지를 받아올 수 있어야 하기 때문에
중복된 코드를 GetImageActivity로 캡슐화했다.
물론 이미지를 필요로 하는 모든 액티비티에서 재사용 가능하다.
1. 이미지를 Gallery 또는 Camera에서 받아온다. (getImageFromGallery, getImageFromCamera)
2. 받아온 이미지를 적합한 사이즈로 가공한다. (workAfterGetFromGallery, workAfteGetFromCamera)
3. 가공한 이미지를 onGetImageFile를 호출해 전달한다.
GetImageActivity를 상속받는 클래스들은 이미지를 받아오는 책임에 대해 건드릴 필요가 없다. (폐쇄)
상속받아 이미지를 받아 어떻게 자신의 책임을 다 할지만 생각하면 된다. (개방)
그렇기 때문에
GetImageActivity의 책임과 관련된 메소드들 최대한 폐쇄해두었다.
getImageFromGallery, getImageFromCamera : FINAL
workAfterGetImageFromGallery, workAfterGetImageFromCamera : FINAL, PRIVATE
추상 메소드 onGetImageFile을 구현해서 자신의 책임에 대해 확장하도록 했다.
FIN
내가 포스팅한 내용은 상속하여 확장하는 클래스의 입장에서의 OCP이다.
다른 사람들의 포스팅을 보니 정말 많은 설명들이 있었다.
인터페이스를 사용한 방법, 추상 메소드를 사용한 방법
상속에서의 OCP, 조립에서의 OCP
많은 OCP의 예가 있으리라 생각하고
그 모든 것들이 OCP라고 생각한다.
초기 원칙을 정할 때 정해진 케이스가 있었을지 몰라도..
결국 OCP의 핵심은
상속을 통한 확장, 인터페이스를 구현한 클래스의 증가, 기능 변경, 알고리즘 교체
같은 어떤 확장을 하더라도 기존의 코드들이 영향을 받지 않는다는 것이다.
'SoftwareDesign' 카테고리의 다른 글
ISP (0) | 2020.03.01 |
---|---|
LSP (0) | 2020.03.01 |
SRP (0) | 2020.03.01 |
SOLID 개요 (0) | 2020.03.01 |
3. Observer (0) | 2020.01.19 |