📘 자바와 객체지향
🟦 객체 지향 설계 5원칙 - SOLID
▪️ SRP(Single Responsibility Principle) : 단일 책임 원칙
▪️ OCP(Open Closed Principle): 개방 폐쇄 원칙
▪️ LSP(Liskov Substitution Principle) : 리스코프 치환 원칙
▪️ ISP(Interface Segregation Principle) : 인터페이스 분리 원칙
▪️ DIP(Dependency Inversion Principle) : 의존 역전 원칙
High Cohesion, Loos Coupling(응집도는 높이고, 결합도는 낮추라)
고전 원칙을 객체 지향 관점에서 재정립 한 것
응집도 : 하나의 모듈(클래스) 내부에 존재하는 구성 요소들의 기능적 관련성
결합도 : 모듈간의 상호 의존 정도
응집도가 높다 -> 모듈은 하나의 책임에 집중, 독립성 높음 -> 유지보수, 기능 수정, 재사용 용이
결합도가 낮다 -> 모듈간의 상호 의존성 낮음 -> 객체의 재사용, 수정, 유지보수 용이SOILD는 객체 지향 4대 특성을 기반으로하며 디자인 패턴의 뼈대, 나아가 스프링 프레임워크의 근간
🔷 SRP : 단일 책임 원칙
"어떤 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 한다" - 로버트 C.마틴
➡️ 책임(역할)을 분리하라는 것
역할과 책임에 따라 분리하여 각각 하나의 역할과 책임만 갖도록 한다.
단일 책임과 가장 관계가 깊은 객체 지향 4대 특성은 추상화
애플리케이션의 경계를 정하고 추상화를 통해 클래스들을 선별하고 속성과 메서드를 설계할 때
반드시 단일책임 원칙을 고려할 것
🔷 OCP : 개방 폐쇠 원칙
"소프트웨어 엔티티(클래스, 모듈, 함수)는 확장에 대해서는 열려 있어야 하지만 변경에 대해서는 닫혀 있어야 한다." - 로버트 C.마틴
➡️ 본인의 확장에는 개방, 주변의 변화에는 폐쇄
예시 : JDBC
Java Application - JDBC interface - JDBC 드라이버 - DBJDBC 드라이버를 각 DB에 맞는 것으로 분리
-> DB가 Oracle에서 MySQL, PostgreSQL 등으로 바뀌더라도 Java Appliation, JDBC interface에는 변화 없음
JDBC interface가 완충 역할을 하여 Java Application은 변화에 영향을 받지 않음
DB는 자신의 확장에 개방(DB 변경)되어 있고 Java Application은 변화에 닫혀 있음
개방 폐쇄 원칙을 무시하고 프로그램을 만든다면 객체 지향 프로그래밍의 가장 큰 장점인
'유연성', '재사용성', '유지보수성'을 얻지 못함
🔷 LSP : 리스코프 치환 원칙
"서브 타입은 언제나 자신의 기반 타입(base type)으로 교체할 수 있어야 한다." - 로버트 C.마틴
하위 클래스 is a kind of 상위 클래스 - 하위 분류는 상위 분류의 한 종류
구현 클래스 is able to 인터페이스 - 구현 분류는 인터페이스 할 수 있어야 함
(인터페이스하다 : AutoCloseable, Appendable, Cloneable, Runnable)위의 문장을 만족한다면 객체 지향의 상속을 잘 만족하는 것이고
리스코프 치환 원칙을 잘 지키고 있다고 할 수 있다.
🔷 ISP : 인터페이스 분리 원칙
"클라이언트는 자신이 사용하지 않는 메서드에 의존 관계를 맺으면 안된다." - 로버트 C.마틴
SRP를 따라 역할과 책임에 따라 클래스를 나누는 것이 아닌
클래스는 그대로 두고 인터페이스를 통해 역할을 나누고 제한시킨다.
//SRP
class 남자 -> class 남편 , class 아들, class 아빠 등으로 분할
//ISP
class 남자 -> interface 남편, interface 아들, interface 아빠 로 역할 제한하여 사용
SRP와 ISP는 같은 문제에 대한 두가지 해결책으로 볼 수 있음
특별한 경우가 아니라면 SRP를 적용하는 것이 더 좋은 해결책
인터페이스 최소주의 원칙
인터페이스를 통해 메서드를 외부에 제공할 때는 최소한의 메서드만 제공하라
인터페이스는 그 역할에 충실한 최소한의 기능만 공개
🔷 DIP : 의존 역전 원칙
"고차원 모듈은 저차원 모듈에 의존하면 안된다. 이 두 모듈 모두 다른 추상화된 것에 의존해야 한다."
"추상화된 것은 구체적인 것에 의존하면 안된다. 구체적인 것이 추상화된 것에 의존해야 한다."
"자주 변경되는 구체(concrete) 클래스에 의존하지 마라" - 로버트 C.마틴
➡️ 자신보다 변하기 쉬운 것에 의존하던 것을 추상화된 인터페이스나 상위 클래스를 두어 변하기 쉬운 것의 변화에 영향받지 않게 하는 것
➡️ 본인보다 변하기 쉬운 것에 의존하지 않는다.
예시 : JDBC
Java Application - JDBC interface - JDBC 드라이버(MySQL) - DB(MySQL)
|- JDBC 드라이버(Oracle) - DB(Oracle)
|- ...자바 애플리케이션은 DB에 곧바로 의존하는 것이 아니라
JDBC 인터페이스를 두어 JDBC 인터페이스에 의존하도록 한다.
🔷 정리
SOLID는 객체지향 4대 특성을 제대로 활용한 결과로 나타난 것
🔹 SoC (Separation Of Concerns) : 관심사의 분리
관심이 같은 것끼리는 하나의 객체 안으로 혹은 가까운 객체로 모은다.
관심이 다른 것끼리는 가능한 따로 떨어트려 서로 영향을 주지 않도록 분리한다.
SoC를 적용하면 SRP, ISP, OCP에 도달하게 되며 스프링이 SoC를 통해 SOLID를 극한까지 적용한 사례이다.
🔹 SOLID
- SRP(단일 책임 원칙) : 어떤 클래스를 변경해야 하는 이유는 오직 하나
- OCP(개방 폐쇄 원칙) : 자신의 확장에는 개방, 주변의 변화에는 폐쇄
- LSP(리스코프 치환 원칙) : 서브 타입은 언제나 자신의 기반 타입으로 교체 가능해야
- ISP(인터페이스 분리 원칙) : 클라이언트는 자신이 사용하지 않는 메서드에 의존 관계 형성 X
- DIP(의존 역전 원칙) : 자신보다 변하기 쉬운 것에 의존 X
김종민, '스프링 입문을 위한 자바 객체 지향의 원리와 이해', 위키북스 참고
