[Spring core basic] 02 - 좋은 객체 지향 프로그래밍이란?

참고

Spring core basic 시리즈는 김영한 님의 "스프링 핵심 원리 - 기본편" 강의를 정리한 글입니다. 글에 첨부된 사진은 해당 강의의 강의 자료에서 캡쳐한 것입니다. 제 Github에만 올려뒀다가, 정보 공유와 강의 홍보(?)를 위해 블로그에도 업로드합니다. 마크다운을 잘 쓰지 못해서 가독성이 조금 떨어지는 점 양해 바랍니다.

 

스프링 핵심 원리 - 기본편 - 인프런 | 강의

좋은 객체 지향 프로그래밍이란?

객체 지향 프로그래밍

컴퓨터 프로그램을 명령어의 목록으로 보는 시각에서 벗어나 여러 개의 독립된 단위, 즉 '객체' 들의 모임으로 파악하고자 하는 것. 각각의 객체는 메세지를 주고받고, 데이터를 처리할 수 있다 (협력)

객체 지향 프로그래밍은 프로그램을 유연하고 변경이 용이하게 만든다.

다형성(Polymophism)

"역할"과 "구현"으로 세계를 구분해보자.

자동차를 운전하는 역할을 가진 "운전자"는, 자동차의 구현(기종)이 바뀌어도 여전히 그 자동차를 운전할 수 있다!

왜냐하면 모든 자동차의 기종은 자동차 역할이라는 "인터페이스"를 기준으로 구현되었기 때문이다!

이렇게 자동차의 역할과 구현을 구분한 이유는 운전자를 위해서라고 볼 수 있다. 구현이 바뀌더라도 자동차의 역할만 동일하면 운전자는 면허를 다시 딸 필요 없이 그대로 운전을 할 수 있다!

자동차의 입장에서 보면, 자동차의 역할만 구현하면 새로운 자동차를 무한히 출시할 수 있다! 즉 클라이언트(운전자)에게 영향을 주지 않고 (면허를 다시 안따도 됨) 새로운 기능을 제공할 수 있다! 자동차라는 역할은 모든 기종이 할 수 있으니까!

이 것이 가능한 이유는 "역할"과 "구현"을 구분했기 때문!

뮤지컬 공연의 각 역할은, 다른 배우로 대체가 가능해야 한다!

로미오와 줄리엣이라는 역할과, 배우라는 구현이 구분되어있기 때문에, 다른 배우로 대체가 가능해진다. 로미오가 장동건에서 원빈으로 바뀐다고 해서, 줄리엣에 영향을 주지 않는다. 마치 서버의 내부 구현이 바뀌어도, 클라이언트의 동작에 영향을 주지 않는 것과 동일하다.

다형성의 실세계 비유

• 운전자 - 자동차
• 공연 역할과 배우
• 세상의 모든 표준 인터페이스 (키보드, 마우스 등)
• 정렬 알고리즘 (내부 알고리즘이 바뀌어도 정렬은 여전히 동일하게 된다)

등등...

역할과 구현을 분리

역할과 구현으로 세상을 구분하면, 단순해지고, 유연해지며, 변경도 편리해진다.

장점

1. 클라이언트는 대상의 역할(인터페이스)만 알면 된다.
   1. 로미오는 줄리엣의 배우가 누구인지 알 필요가 없다. 줄리엣 역할, 대본만 알면 상대해서 연기할 수 있다.
2. 클라이언트는 구현 대상의 내부 구조를 몰라도 된다.
   1. 테슬라의 내부 구조를 몰라도 운전 가능하다.
3. 클라이언트는 구현 대상의 내부 구조가 변경되어도 영향을 받지 않는다.
   1. 테슬라에 옵션이 추가되어도 여전히 운전 가능하다.
4. 클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않는다.
   1. K3에서 테슬라로 차를 바꿔도 여전히 운전이 가능하다.

객체의 협력이라는 관계부터 시작하자

혼자 존재하는 객체는 없다. 수 많은 객체 클라이언트와 객체 서버는 서로 협력 관계를 가진다.

객체끼리 서로 요청하고, 응답을 하는 관계가 합쳐지며 커져서 커다란 프로그램이 된다.

Java에서의 다형성(Polymophism)

역할 = 인터페이스
구현 = 인터페이스를 구현한 클래스 (그 클래스를 구현한 객체)

객체를 설계할 때 역할과 구현을 명확히 분리한다!
객체 설계시 역할(인터페이스)을 먼저 부여하고, 그 역할을 수행하는 구현 객체를 만든다.

*물론 인터페이스 말고 일반 상속 관계로도 다형성을 구현할 수 있다. 핵심은 구현보다 역할 부여가 먼저라는 것!

클라이언트는 MemberRepository interface (역할)에 의존한다.

위 그림에서 상속 관계에 의해 다음과 같은 코드가 가능하다.

public class MemberService
{
    //둘 다 가능하다!
    //private MemberRepository mr = new MemoryMemberRepository();
    private MemberRepository mr = new JDBCMemberRepository();
}

하나의 역할에 여러 구현이 붙을 수 있다.

다형성의 본질

다형성의 본질을 이해하려면 협력이라는 객체 사이의 관계에서 시작해야 한다.

인터페이스를 구현한 객체 인스턴스를 실행 시점에 유연하게 변경할 수 있다!

클라이언트를 변경하지 않고, 서버의 구현 기능을 유연하게 변경할 수 있다!

지금까지 정리

1. 세상을 역할과 구현으로 구분한다는 편리한 컨셉을, 다형성을 통해 객체 세상으로 가져올 수 있다.
2. 다형성을 통해 유연하고, 변경이 용이한, 확장 가능한 설계가 가능하다.
3. 클라이언트에 영향을 주지 않고 변경이 가능하다.
4. 인터페이스를 안정적으로 잘 설계하는 것이 중요하다 (인터페이스가 변경되면...?)

다형성의 한계

1. 역할(인터페이스) 자체가 변하면, 클라이언트와 서버 모두에 큰 변경이 발생한다.
   1. 자동차를 비행기로 변경해야 한다면? -> 운전자는 비행기 면허를 따야한다...
   2. 공연의 대본 자체가 변경된다면?
   3. USB 인터페이스가 변경된다면?

인터페이스를 안정적으로 (변경될 가능성을 최소화해서) 잘 설계하는 것이 중요하다!

Spring과 객체 지향

다형성은 객체 지향의 꽃이다.

Spring은 다형성을 극대화해서 이용할 수 있게 해준다.

• Spring에서 이야기하는 IoC(제어의 역전), DI는 다형성을 활용해서 역할과 구현을 편리하게 다룰 수 있도록 지원한다!
• Spring을 사용하면 레고 블럭 조립하듯이 구현을 편리하게 변경할 수 있다!