📌 좋은 객체지향?
프로그램을 유연하고 변경이 용이하게.
-> 컴포넌트를 쉽고 유연하게 변경하면서 개발.
스프링 프레임워크만 단독으로 사용하기 보단 여러 스프링 관련 프로젝트를 함께 사용한다.
스프링은 다형성을 극대화해서 이용할 수 있게 도와준다. 스프링에서 이야기하는 제어의 역전(IoC), 의존관계 주입(DI)은 다형성을 활용해서 역할과 구현을 편리하게 다룰 수 있도록 지원한다.
역할과 구현으로 세상을 구분한다.
로미오 역할을 맡은 배우가 장동건이든 원빈이든 그 역할은 그대로이므로 줄리엣 역할을 하는 배우가 로미오 배역에 신경 쓸 필요는 없다.
마찬가지로 자동차가 BMW이든 모닝이든 구현체가 바뀌어도 자동차 역할은 그대로이고 이를 운전하는 운전자도 제 역할은 그대로이므로 운전자가 면허를 새로 취득하는 등의 행위를 할 필요가 없는 것이다.
이처럼 역할과 구현으로 구분하면 세상이 단순해지고, 유연해지며 변경도 편리해진다.
📌 정리
- 클라이언트는 대상의 역할(인터페이스)만 알면 됨
- 클라이언트는 구현 대상의 내부 구조를 몰라도 됨
- 클라이언트는 구현 대상의 내부 구조가 변경되어도 영향을 받지 않는다
- 클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않는다
객체를 설계할 때 역할과 구현을 명확히 분리한다. 즉, 역할(인터페이스)을 먼저 부여하고, 그 역할을 수행하는 구현 객체를 만든다.
혼자 있는 객체는 없으며 수 많은 객체 클라이언트와 객체 서버는 서로 협력 관계를 가진다는 점을 생각하자.
@Override
를 생각해보면, 다형성을 바탕으로 인터페이스를 구현한 객체를 실행 시점에 유연하게 변경할 수 있다. 클라이언트를 변경하지 않고, 서버의 구현 기능을 유연하게 변경할 수 있다.
스프링은 다음 기술로 다형성 + OCP, DIP를 가능하게 지원한다.
이를 통해 클라이언트 코드의 변경 없이 기능 확장이 가능하다. 쉽게 부품을 교체하듯이 개발하는 원리이다. 결국 인터페이스를 도입 시 발생하는 추상화라는 비용에 유의하여 모든 설계에 역할과 구현을 분리하여 유연하게 변경할 수 있도록 객체 지향적으로 설계하도록 하자.