프로그래머(뉴비)

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의 핵심은

상속을 통한 확장, 인터페이스를 구현한 클래스의 증가, 기능 변경, 알고리즘 교체

같은 어떤 확장을 하더라도 기존의 코드들이 영향을 받지 않는다는 것이다.

SRP (Single Reponsibility Principle; 단일 책임 원칙)

한 클래스는 하나의 책임을 가져야 한다.

클래스가 변경되는 이유가 하나여야 한다.

SRP가 뭐지?

사진을 추가할 수 있는 메모 앱을 만드려고 한다.

메모를 작성하는 화면과 수정하는 화면이 필요하다.

거의 비슷한 동작을 할 것이다.

두 개의 클래스를 만든다면 분명 중복 코드가 생기게 된다.

그래서 천재적으로 하나의 MemoManipulateAcitivity를 만들었다.

짠! 아주 책임이 가득한 클래스가 완성되었다.

SRP고 뭐고 잘 동작한다.

나는 훌륭하게 일을 해냈다.

작성일자와 수정일자를 표시하는 요구사항이 추가되었다.

코드를 수정하고 메모를 작성해 보니 잘 표시한다. 출시!

출시하고 보니 수정할 때마다 작성일자가 오늘일자로 수정된다.

아 수정하는 일도 했었지...

한 클래스에 두가지의 책임이 공존해 실수가 나왔다.

프로필 화면에서 사진을 추가하는 요구사항이 추가되었다.

프로필 화면에서도 이미지를 받아와야 하는데 코드가 중복된다....

하나의 책임에 집중하지 못한 클래스는 재사용하기 힘들다.

하나의 책임에 집중해보자

클래스당 하나의 책임만 가지도록 만들어 보자

하나의 책임을 가지도록 클래스를 분리했다.

각 클래스는 하나의 책임에 집중한 적은 양의 코드만 남았다.

이미지를 받아오는 코드를 캡슐화 했다.

이를 통해 중복코드없이 프로필 설정화면에도 재사용할 수 있게 되었다.

메모 작성 화면과 수정 화면의 공통 조작 부분을 MemoManipulateActivity로 캡술화하고

두 클래스에 의존적인 메모를 만드는 부분은 추상 메소드 getMemo로 만들었다.

이로 인해 작성 화면과 수정 화면은 서로 불필요한 영향을 받을 일이 줄고 자신의 책임에 집중할 수 있다.

외부 포스팅

더 자세하게 깊게 알고 싶다면..

https://velog.io/@amobmocmo/Software-Design-SRP-Single-Responsibility-Principle-4pk2aklhqo

로버트 C. 마틴 제시한 5가지 원칙

물론 다 본인이 만든건 아니라고 한다.

LSP 법칙만 봐도 아니라는 것을 알 수 있다.

개발자라면 무조건 듣게 되는 원칙이라고 생각한다.

나도 많이 들었고 봤다가 잊어버렸다가를 반복하기에 정리하려 한다.

개인적으로는 완전히 이해하고 정리하기 쉽지 않았다.

(지금도 완전히 이해했는지 잘모름)

또 실무에서 상황상 적용하기 힘들 수도 있고

적용한 것이 더 안좋은 경우가 있을 수도 있다.

하지만 알고 적용하지 않는 것과 몰라서 적용하지 못하는 것은 다른 이야기이다.

위키피디아 내용

위키피디아에 써있는 한줄 설명이다.

SRP (Single Reponsibility Principle; 단일 책임 원칙)

한 클래스는 하나의 책임만 가져야 한다.

OCP (Open/Cloesed Priciple; 개방-폐쇄 원칙)

소프트웨어 요소는 확장에는 열려있으나 변경에는 닫혀있어야 한다.

LSP (Liskov Substitution Principle; 리스코브 치환 법칙)

프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.

ISP (Interface Segregation Principle; 인터페이스 분리 법칙)

특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.

DIP (Dependency Inversion Principle; 의존 역전 법칙)

프로그래머는 “추상화에 의존해야지, 구체화에 의존하면 안된다.". DI(의존성 주입) 역시 이 원칙을 따르는 방법 중에 하나이다.

https://ko.wikipedia.org/wiki/SOLID_(%EA%B0%9D%EC%B2%B4_%EC%A7%80%ED%96%A5_%EC%84%A4%EA%B3%84)

완벽하게 이해하려고 각각의 원칙들의 위키를 읽다가 더 이해하기 힘들었다.

많은 포스팅을 보고 원칙이 전하려는 의미를 파악하는게 더 쉬울 것이라고 생각한다.

하지만 포스팅들을 보면 이해하는 것도 가지각색이고 아다르고 어다르게 설명하는 경우도 부지기수이다.

최대한 많이 보며 공통의 내용이 무엇인지 파악해보자.

다른 포스팅 잘못된 포스팅들을 보면서 공부하고 생각하다 보면 이 또한 공부가 된다.