지난 편 OOP 이론 내용이 너무 길어져서 SOLID는 따로 빼서 정리하려 한다.
SOLID는 OOP의 5대 원칙이라고도 불리는데, 원칙이라는 말이 붙을 정도로 널리 인정받는 내용이다.
SOLID 원칙을 통해 추구하고자 하는 바는 다음과 같다.
좋은 소프트웨어는 결합도는 낮추고 / 응집도는 높여야 한다.
결합도 : 모듈 간의 상호 의존 정도를 나타내는 지표
-> 낮을 수록 서로의 변경에 따른 영향도가 적어짐
응집도 : 하나의 모듈 내부에 존재하는 구성요소들의 기능간 관련성
-> 높을 수록 하나의 책임에 집중하게 되고 독립성이 강해짐목표 : 낮은 결합도와 높은 응집도를 통해 재사용과 유지보수를 쉽게하자!
이제 5대 원칙을 하나하나 정리해보자.
- SRP(단일 책임 원칙) - Single Responsibility Principle
모든 Class는 하나의 책임만을 가진다.
(Class를 변경해야 하는 이유는 한가지 뿐이어야 한다.)
위의 경우 만약 File Reader(String str)을 File Reader(File file)로 변경하고자 하면
해당 부분 뿐 아니라 File이 연관성을 가지고 있는 FileReader 부분도 변경해야 한다.
하지만 위와 같이 해당 부분을 Class로 완전히 분리하여 연관성을 없애고 하나로 만든다면
수정시 File Reader() 부분만 변경 해주면 된다.
(기능 단위로 Class를 분리하고 독립적으로 존재하도록하여 결합도를 낮추고 응집도를 높힘)
- OCP(개방 폐쇄 원칙) - Open Closed Principle
개체는 확장에는 열려있어야 하지만 수정에 있어서는 닫혀 있어야 한다.
(상위 클래스나 인터페이스를 중간에 두고 확장에 활용)
OCP 원칙이 적용된 대표적인 예로는 JDBC Interface를 들 수 있다.
JDBC는 그 자신의 변경에 대해서는 닫혀있지만
각기 다른 DBMS 시스템에 대해 각각의 Driver를 사용할 수 있도록 확장이 가능하다.
- LSP(리스코프 치환 원칙) - Liskov Substitution Principle
하위 타입은 언제나 자신의 상위 타입으로 교체 할 수 있어야 한다.
오른쪽의 경우 하위 타입인 정찰기와 수송기는 상위 타입인 공중 유닛과 비행기가
될 수 있으므로 LSP를 위반하지 않는다.
그러나 왼쪽의 경우처럼 아무리 소나타와 그랜저가 아반떼의 기본 설계를 가지고 만들었다고 해도
소나타와 그랜저가 아반떼가 될 수는 없으므로 LSP를 위반하고 있다.
- ISP(인터페이스 분리 원칙) - Interface Segregation Principle
클라이언트는 자신이 사용하지 않는 Method에 의존 관계를 맺으면 안된다.
(프로젝트나 설계에 따라 SRP나 ISP 원칙을 선택하여 사용)
자전거 내비는 지도를 상속 받는게 아니라 지도를 상속받은 자전거 길 안내를 상속 받는다.
- DIP(의존 역전 원칙) - Dependency Inversion Principle
자신보다 변하기 쉬운 것에는 의존하지 말아야 한다.
이 관계에서는 사람이 계절마다 변하는 계절 옷에 의존하고 있다.
바람직한 방법은 계절 옷이 의존하는 옷에 의존하는 것이다.
강의의 마지막 물음에서 내 Code들을 떠올려보니 아직 갈 길이 멀다.
그래도 이렇게 정리 해두었으니 가끔씩 다시 보면서
내가 Guide를 잘 따르고 있는지 돌이켜 볼 수 있는 포스팅이라 생각한다.
(꼭 다시보자!)
