객체지향 5원칙 SOLID

객체지향 5원칙

 

1. SRP(Single Responsibility Principle) 단일 책임 원칙

객체로 정의한 대상은 하나의 책임만 가지도록 해야한다는 원칙.

예로 생물 <- 포유류 <- 개,고양이 형식으로 많이 나온다. 이해를 돕기 위해서..

문제는 이렇게 물리적 형상을 알고 특성을 바로 알 수 있는거라면 어렵지도 않다.. 

실제적으로 존재하는 개, 고양이라는 객체가 있고 생물, 포유류는 포괄하는 개념이니까.

속성(멤버변수)도 명확하고 동작(멤버함수)도 명확하다. 

하지만 실제적으로는 실제하는 객체보다는 개념적인 객체에 팔과 다리를 붙이고 눈, 코, 입을 단다. 

여기서 코를 잘못 달수도 있고 다리가 팔에 갈수도 있고 팔이 8개일수도 있다. 

이건 누가 알려주기보다는 팔을 넣기전에 이 팔은 이 객체의 것이 맞는지 매번 고민하고 틀리면 고치면서 

체득하는 것밖에 없는 것 같다. 

 

2. OCP(Open Closed Principle) 개방 폐쇄 원칙

확장에는 열려있고 수정에는 닫혀있는 구조로 설계되거나 프로그래밍 되어야한다는 원칙.

이 원칙은 유지보수할 때 원칙인 것 같다. 기존에 운영하고 있는 서비스가 있는데 거기서 수정을 하면?

무수한 버그와 에러들을 만날것이다. 이건 장담한다. 

아무리 정리를 잘해 놨더라도 세세하게 기억하던 그 시절 같을 순 없으리오~

기존에 만들어 놓은 기능을 수정해야 할 상황이 온다면? 새로 클래스를 짜는게 낳다. 

인터페이스 위주로 구조를 설계 했다면 해당 인터페이스 상속받고 해당 클래스만 교체하면 끝. 

기존꺼는 건들지 말자.  

 

3. LSP(Liskov Substitution Principle) 리스코프 치환 원칙

부모객체를 상속한 자식객체는 반드시 부모객체의 인터페이스를 모두 구현해야 한다는 원칙. 

자식(Sub-type)은 부모(Super-type)로 치환될 수 있다.​

예로 나왔던 생물, 포유류, 개에서 개 = 포유류가 될수 있지만 포유류 = 개는 될수 없다는 것이다. 

고양이도 있으니까.. 

 

4. ISP(Interface Segregation Principle) 인터페이스 분리 원칙

사용자에게 제공되어지는 인터페이스는 최소한의 단위로 분할되어 제공되어져야한다는 원칙.

예를 들면 은행관련 입금, 송금, 출금 모듈을 만들었을 경우 골라서 사용할 수 있어야 한다.

어찌보면 객체아닌 객체의 묘미를 부릴수 있다. 양의 다리와 전갈 꼬리를 만들고 사자의 몸과 사람의 머리를 단다.

그야말로 키메라. 가능하다. 그러니 주의하자. 적어도 정상적인 녀석은 만들어야지.. 잡캐는 망캐에 다른말이라던가

 

5. DIP(Dependency Inversion Principle) 의존성 역전 원칙

높은 수준의 객체가 보다 하위수준의 객체에 의존성을 가지지 않아야 하며, 반대로 하위 수준의 객체가 보다 높은 추상화 수준의 객체에 의존해야 한다는 원칙. 

개가 될지, 고양이가 될지 모르는 객체를 참조하지 말고 포유류 객체를 참조하는 형식으로 해서 확장에 용이하게 하라는 말이다. 

'패턴 그리고 객체지향적 코딩의 법칙' 이라는 책에서 보면 간편하게 

공통점 묶기, 조금만 알기

이 두개로 끝이다. 두가지에 중점을 두고 만들고 고치다보니 무슨무슨 패턴이라든지 객체지향적 코딩이라든지가 된단다. 좀 더 세부적인 것은 고민하면서 만들어가자. 

[출처] 객체 지향 5원칙 SOLID|작성자 쏭아리

참고 사이트

http://blog.naver.com/ssongah/220111892196