객체 지향 설계 원칙 : '응집도 높이고 결합도 줄이자' 이것을 객체 지향 관점에서 재정의한 것.
- 결합도 : 클래스 간 상호 의존 정도. 결합도가 낮으면 모듈 간 상호 의존성이 줄어들어 객체의 재사용, 수정, 유지보수 용이
- 응집도 : 하나의 모듈 내부에 존재하는 구성 요소들의 기능적 관련성. 응집도 높으면 하나의 책임에 집중하고 독립성 높아져 재사용, 기능 수정, 유지보수 용이
SRP 단일 책임 원칙
"어떤 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 한다."
역할과 책임에 따라 클래스, 속성, 메서드, 패키지, 모듈, 컴포넌트, 프레임워크 등을 쪼개자.
-> 데이터베이스의 정규화와 비슷.
-> 객체 지향 4대 특성 중 추상화와 관계가 깊다.
OCP 개방 폐쇄 원칙
"자신의 확장에는 열려있고, 주변의 변화에 대해서는 닫혀 있어야 한다."
-> JDBC
JDBC를 사용하는 클라이언트는 데이터베이스가오라클에서mysql로 바뀌더라도 커넥션을 설정하는 부분 외에는 따로 수정할 필요가 없다.- 커넥션 설정 부분을 별도의 설정 파일로 분리해두면 클라이언트 코드는 단 한줄도 변경할 필요가 없다.
-> JVM
- 자바 개발자는 작성하고 있는 소스코드가 윈도우, 맥, 리눅스 어디에서 구동될지 (또 다른 운영체제 상도 마찬가지)에 대해서 걱정할 필요 없다.
- 개발자가 작성한 코드는 운영체제의 변화에 닫혀있고, 각 운영체제별
JVM은 확장에 열려 있는 구조다.
-> myBatis, 하이버네이트 등등 데이터베이스 프로그래밍 지원하는 라이브러리와 프레임워크에서도 볼 수 있음.
LSP 리스코프 치환 원칙
"하위 클래스의 인스턴스는 상위형 객체 참조 변수에 대입해 상위 클래스의 인스턴스 역할을 하는데 문제가 없어야 한다."
"서브 타입은 언제나 자신의 기반 타입으로 교체할 수 있어야 한다."
- 하위 분류는 상위 분류의 한 종류다.
- 구현 분류는 인터페이스 할 수 있어야 한다.
ex. 고래가 포유류 또는 동물의 역할을 하는 것은 전혀 문제가 되지 않는다.
ISP 인터페이스 분리 원칙
"클라이언트는 자신이 사용하지 않는 메서드에 의존 관계를 맺으면 안된다."
클래스를 쪼개기보다는 인터페이스를 나눠서 제한.
즉, 단일 책임 원칙(SRP)과 인터페이스 분할 원칙(ISP)은 같은 문제에 대한 두가지 다른 해결책이다.
둘 중 하나를 선택해서 설계할 수 있는데 특별한 경우가 아니라면 단일 책임 원칙을 적용하는 것이 더 좋은 해결책이다.
DIP 의존 역전 원칙
" 추상화된 것은 구체적인 것에 의존하면 안된다. 구체적인 것이 추상화된 것에 의존해야한다."
-> 자신보다 변하기 쉬운 것에 의존하지 마라.
상위 클래스일수록, 인터페이스일수록, 추상 클래스일수록 변하지 않을 가능성이 높다. 따라서 이를 의존하라.(OCP와 밀접한 관련이 있다.)
-> 대표 사례 : JDBC.
SOLID와 밀접한 것 : SoC 관심사의 분리.
관심이 같은 것끼리는 하나의 객체 안으로 또는 친한 객체로 모으고,
관심이 다른 것은 가능한 한 따로 떨어져 서로 영향을 주지 않도록 분리하라.
하나의 속성, 하나의 메서드, 하나의 클래스, 하나의 모듈, 또는 하나의 패키지에는 하나의 관심사만 들어 있어야 한다!
SOLID원칙을 적용하면 소스 파일의 개수는 더 많아지겠으나 이렇게 많아진 파일이 논리를 더욱 잘 분할하고, 이해하기 쉽고, 개발하기 쉽고, 유지보수하기 쉬워진다.
스프링 입문을 위한 자바 객체 지향의 원리와 이해
