객체지향 원칙 SOLID 는
이 원칙들을 알아야 하는 이유는 객체지향을 베스트 프랙티스로 사용하기 위한 노하우들이 정의된 것이므로 이 원칙들을 적절하게 준수한다면 잘못된 객체지향 사용으로 인한 사이드 이펙트를 방지할 수 있습니다.
객체지향을 잘못 사용하게 되면 기능을 구성하는 객체들의 응집도가 낮아지고 결합도는 높아지면서 변경에 취약하게 됨으로써 기능 추가나 요구사항 변경을 반영할 때 리소스가 초기 개발보다 배로 투입이 되는 문제가 발생할 수도 있습니다.
SRP 는 단일책임원칙으로서 객체는 하나의 책임만 져야한다는 원칙이며 클래스가 수정되어야 하는 이유는 오로지 해당 책임에 관련된 것이어야만 한다는 원칙입니다.
하나의 책임을 짐으로써 객체의 캡슐화가 올바르게 될 수 있고 하나의 책임을 수행하는 상태나 행위들이 모이게 돼 응집도가 높아집니다.
만일 객체에 여러 책임이 섞여있다면 하나의 책임에 대해 변경이 필요할 때 다른 책임에 관련된 코드들도 영향을 받을 수 있습니다. 그리고 객체가 지나치게 거대해질 수도 있습니다.
OCP는 개방 폐쇄 원칙으로 자신의 변경에는 열려있고 다른 객체의 변경에는 닫혀 있어야 한다는 원칙입니다.
JDBC를 예로 들면 DAO 클래스가 추상화된 트랜잭션 매니저 클래스와 의존관계에 있을 때 트랜잭션과 관련된 DB 로우레벨 코드는 트랜잭션 매니저 구현체가 수행함으로써 DAO 클래스는 자신의 책임에만 집중하고 변경이 필요하다면 오롯이 자신의 책임과 관련된 이유로만 변경하면 되고 트랜잭션 매니저 구현체가 변경이 되어도 영향을 받지 않습니다.
LSP 는 리스코프 치환 원칙으로서 자식 타입은 언제나 부모 타입을 대체할 수 있다는 원칙입니다.
자식 타입에서 재정의된 메서드의 내용이 부모 타입의 책임과 완전히 다른 내용이 되어서는 안됩니다.
예를 들면 Queue 클래스의 pop() 은 FIFO로 동작하는데 자식 클래스에서재정의 된 메서드는 LIFO는 동작되면 안됩니다.
ISP는 인터페이스 분리 원칙으로 최소 행동주의 원칙이라고도 합니다.
단일 책임 원칙을 지키기 위해 클래스를 분리하는 방법도 있지만 이 원칙의 경우에는 행위로 인터페이스를 분리하는 것입니다. 행위를 최소한 작게 가져가야 이 인터페이스를 구현할 때 불필요한 행위들까지 오버라이딩 하지 않기 때문입니다.
의존 역전 원칙으로서 의존 관계를 맺을 때 구체 클래스에 의존하지 않고 추상화된 것에 의존하라는 원칙입니다. 추상화된 것에 의존하면 의존관계 결합도를 낮춰서 의존하고있는 객체가 변경이 되어도 영향을 최소화할 수 있게 됩니다.
이 사례도 JDBC를 예로 들면 어플리케이션 로직 계층에서는 추상화된 Connection 에 의존하기 때문에 구체적인 DB 커넥션 클래스는 언제든지 변경할 수 있습니다.