Spring이 생겨난 핵심적인 요인 중 좋은 객체지향 설계를 위함이 있다.
객체 지향 설계를 잘 하기 위해서는 SOLID 원칙을 중요하게 생각하고 설계를 하면 된다.
clean code로 유명한 로버트 마틴이 좋은 객체 지향 설계의 5가지 원칙을 정리를 한 이론이다. (기존에도 이론 자체는 있었음)
한 클래스는 하나의 책임만 가져야 한다.
하나의 책임은 클수도 있고 작을수도 있으며 문맥과 상황에 따라 다르기 때문에 모호하지만, 클래스의 변경이 있을 때 파급 효과가 적도록 분리시켜 놓는 것이 단일 책임 원칙을 잘 지키는 것이라고 생각하면 된다.
소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
이게 뭔 말인가 싶지만, 다형성을 이용하여 변경을 최소화 한다고 생각하면 된다.
예시) 인터페이스를 구현한 새로운 클래스를 하나 더 만들어서 새로운 기능을 구현 후 교체
프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
인터페이스를 구현한 구현체는 믿고 사용하기 위해서는 아래 원칙들이 필요하다.
예시) 자동차 인터페이스의 엑셀은 앞으로 가라는 기능, 뒤로가게 구현하면 LSP 위반, 느리더라도 앞으로 가야함.
특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
예시) 자동차 인터페이스 -> 운전 인터페이스, 정비 인터페이스로 분리
사용자 클라이언트 -> 운전자 클라이언트, 정비사 클라이언트로 분리
분리하면 정비 인터페이스 자체가 변해도 운전자 클라이언트에 영향을 주지 않으며 인터페이스가 명확해지고 대체 가능성이 높아진다.
"프로그래머는 추상화에 의존해야지 구체화에 의존하면 안된다."
쉽게 이야기해서 기능이 구체화 한 구현 클래스가 아닌 인터페이스에 의존해야 한다는 것이다.
그래야 변경에 있어서 의존성이 낮고 기능이 수정되더라도 조금의 코드만 수정하면 바뀔 수 있기 때문이다.
객체 지향의 핵심은 다형성이다. 하지만 다형성 만으로는 쉽게 부품을 갈아 끼우듯이 개발할 수 없다. 왜냐하면 다형성 만으로는 구현 객체를 변경할 때 클라이언트 코드도 함께 변경해야 하기 때문이다. 다형성만으로는 OCP, DIP를 지킬 수 없다.