Spring) 다형성 Polymorphism

다형성이란?

• 하나의 객체가 여러 타입을 가질 수 있는 것을 말한다. 자바로 코딩을 하다 보면 업캐스팅/다운캐스팅을 사용해서 하나의 자료형으로 여러 타입의 객체를 생성하는 경우가 많다. 이것이 다형성의 대표적인 예라고 할 수 있다.
  
  

객체지향프로그래밍에서 다형성이 중요한 이유

• 객체지향프로그래밍의 꽃은 다형성이라 할 수 있을 것이다. 객체지향프로그래밍 하면 빼놓을 수 없는 자바와 스프링도 다형성이 없으면 돌아가지 않을 것이다. 그렇다면 왜 이렇게 중요한 걸까?

역할과 구현의 분리

• 역할과 구현을 분리한다는 말이 처음에는 참 어렵게 느껴진다. 솔직히 무슨 말인가 싶었다…ㅋㅋㅋ
• 자동차와 운전자를 예로 들면, 운전자는 운전만 할 줄 알면 세상의 모든 차를 운전할 수 있다. 왜냐면 자동차의 운전 방식은 똑같으니까. 자동차가 바뀐다고 운전 방법이 달라지지는 않는다. 그래서 운전자는 운전 방법만 알고 있으면 된다.

• 하지만 자동차는 운전 방법만으로 이루어지지 않는다. 자동차에는 내연기관도 필요하고 바퀴도 필요하고 본체도 필요하고 핸들의 움직임도 제어할 수 있어야 하고… 자동차의 구성 요소가 동작하게 할 각종 매커니즘이 필요하다. 그런데 이런 매커니즘을 몰라도 운전은 할 수 있다. 안다고 손해는 없겠지만 운전자는 운전만 하면 되는데 머리 아프게 이런 것들까지 꼭 알아야 할까?

• 그래서 나온 개념이 역할과 구현을 분리하는 것이다.
• 운전자 입장에서 자동차는 운전해서 이동할 수 있다는 역할을 한다는 것만 알고 있으면 된다. 내부 구조가 어떻게 돌아가는지까지는 몰라도 상관이 없다. 자동차의 내부 구조는 그걸 구현하는 회사가 알고 있으면 된다.

• 여기서 나오는 개념이 바로.. 인터페이스이다. 오늘에서야 인터페이스의 존재 이유를 명확하게 알게 되었는데, 처음에는 굳이 이걸 왜? 였다.

• 자동차를 만드는 회사는 운전할 수 있는 차라는 인터페이스(역할)를 운전자에게 제공하기만 하면 내부 구조를 어떻게 만들든 운전자는 운전을 할 것이다. 그러면 자동차 회사는 하나의 인터페이스 안에서 여러 모델의 차를 만들 수 있을 것이다. 디자인과 기능이 어떻게 되었든 운전만 되면 되니까.
• 이런 방식으로 코딩하면 사용자에게 제공할 차의 종류나 기능이 바껴도 제공하는 부분을 일일이 뜯어고치지 않고 구현하는 내부만 고치면 된다. 사용자 100명에게 제공하고 있지만 실제로 구현하는 클래스 하나만 수정하면 되는 것이다. 만약 100명에게 일일이 실제 구현체를 제공하는 코드를 작성했다면…… 그 부분 수정하다가 날이 저물 것이다.

자바에서의 다형성

• 역할 = 인터페이스
• 구현 = 인터페이스를 구현한 클래스, 구현 객체
• 객체를 설계할 때엔 역할과 구현을 명확하게 분리해야 한다. 이를 위해서는 객체의 역할을 먼저 부여한 다음 그 역할을 수행하는 구현 객체를 만드는 것이 좋다.
  
  

객체지향 SOLID 원칙

• 이번 정보처리기사 실기에 출제되어 나를 괴롭게 했던…^^ SOLID 원칙을 알아보자.

SRP 단일 책임 원칙

• Single responsibility principle
• 한 클래스는 하나의 책임만 가져야 한다.
• 하나의 책임이라는 기준이 다소 모호할 수 있다. 중요한 기준은 변경으로, 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것이다.
• 예) UI 변경, 객체의 생성과 사용을 분리

OCP 개방-폐쇄 원칙

• Open/closed principle
• 소프트웨어의 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
• 참 모순된 말이지만 다형성과 스프링 프레임워크를 사용하면 이것을 손쉽게 구현할 수 있다.
• 대표적인 예는 하나의 인터페이스를 활용한 여러 타입의 객체 생성이다.

LSP 리스코프 치환 원칙

• Liskov substitution principle
• 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
• 하위 클래스는 인터페이스 규약을 다 지켜야 하는 것이다.
• 예) 자동차 인터페이스의 엑셀은 앞으로 가는 기능으로 정의했다. 그런데 이걸 뒤로 가게 구현하면 LSP 원칙을 위반하는 것이다. 무조건 앞으로 가게 구현해야 LSP 원칙을 지키는 것이다.

ISP 인터페이스 분리 원칙

• Interface segregation principle
• 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
• 예) 자동차 인터페이스 -> 운전 인터페이스, 정비 인터페이스로 분리
• 사용자 클라이언트 -> 운전자 클라이언트, 정비사 클라이언트로 분리
  • 분리하면 정비 인터페이스 자체가 변해도 운전자 클라이언트에 영향을 주지 않는다.
• 인터페이스가 명확해지고 대체 가능성이 높아진다.

DIP 의존관계 역전 원칙

• Dependency inversion principle
• 프로그래머는 추상화에 의존해야지, 구체화에 의존하면 안 된다.
• 의존성 주입은 이 원칙을 따르는 방법 중 하나다.
• 구현 클래스에 의존하지 않고 인터페이스에 의존하라는 뜻. 즉 역할에 의존하게 해야 한다. 구현체에 의존하게 되면 변경이 아주 어려워진다.
  
  

스프링이란?

• 객체지향프로그래밍에서 처음에는 객체가 각자 분리되어야 한다고 생각하기 쉽다. (내가 그랬다)
• 하지만 본질은 그것이 아니다!
• 객체간의 협력으로 이루어지는 것이며 요청하는 클라이언트와 응답하는 서버가 있는 것이다.
• 다형성의 가장 중요한 본질은 클라이언트를 변경하지 않고, 서버의 구현 기능을 유연하게 변경할 수 있다는 것이다.
• 스프링은 이러한 다형성을 극대화해서 이용할 수 있게 도와주는 것이다. 쉬운 건 아니긴 한데 그렇다고 으마무시하게 복잡한 기술은 아닌 것이다…
• 스프링에서 제공하는 DI(Dependency Injection)을 이용해 다형성과 OCP, DIP를 쉽게 구현할 수 있다.
  • 클라이언트의 코드의 변경 없이 기능을 확장할 수 있으며 쉽게 부품을 교체하듯이 개발할 수 있다.
    
    

참고

• 스프링 핵심 원리 - 기본편