#1 객체지향 프로그래밍

캡슐화, 추상화, 상속, 다형성... 많이 들어봤지만, 정작 객체지향적인 코드를 사용하면 좋은지 잘 모르는 경우가 많다. 해당 글에서는 객체지향적인 개념이 왜 생겼고, 스프링 프레임워크가 지향하는 객체지향은 무엇인지 알아보자.

---

# 다형성의 본질

다형성의 본질은 인터페이스를 구현한 객체의 인스턴스를 실행 시점에서 유연하게 변경할 수 있다는 것이다.

쉽게 말하면 다형성을 구현하면 클라이언트를 변경하지 않고 서버의 구현 기능을 유연하게 변경할 수 있다.

다형성, 역혈과 구현을 분리하라.

1. 실제 서비스에서 혼자 있는 객체는 없다.

• 클라이언트 : 요청 , 서버: 응답
• 수 많은 객체 클라이언트와 각각의 객체 서버들은 협력 관계를 가진다.

 

2. 역할과 구현을 분리해서 설계하면 많은 장점이 있다. => 다형성

• 클라이언트는 대상의 역할(=인터페이스)만 알면 된다.
• 클라이언트는 구현 대상(=클래스, 객체)의 내부 구조를 몰라도 된다.
• 클라이언트는 구현 대상의 내부 구조가 변경되어도 영향 받지 않는다.
• 클라이언트는 구현 대상 자체를 다른 것으로 변경해도 영향 받지 않는다. 
• 유연하고 변경이 용이하여 확장이 쉽다.

 

하지만 다형성을 구현한 인터페이스를 설계하는건 매우 어렵다. 일단 대충 만들어놓고 나중에 인터페이스를 수정하면 결국에는 클라이언트, 서버에 모두 큰 변경이 발생하기에 다형성을 구현한 의미가 없어진다.

 

스프링 프레임워크의 핵심 기능은 자바 코드의 다형성을 극대화하여 구현할 수 있게 도와주는 것이다. 스프링에서 이야기하는 제어의 역전(IoC) 나 의존관계 주입(DI)은 역할과 구현을 편리하게 다뤄 다형성을 쉽게 구현하게 만들어준다.

 

---

# 좋은 객체지향의 설계 5원칙 (SOLID)

스프링에서는 IoC나 DI와 같은 개념뿐만아니라 객체지향적인 설계 원칙을 이용하여 설계되어있다. 스프링 프레임워크 코드를 볼 일이 있을진 모르겠지만, 살펴본다면 아래의 원칙들을 정말 철저하게 지키려고 노력한 흔적들이 남아있다.

참고로 개발자들 사이에서 유명한 객체지향 설계의 5원칙 SOLID는 CleanCode 책으로 유명한 로버트 마틴이 객체지향의 5원칙(Principle)의 앞글자를 이어 붙인 것이다.

 

@ SRP (Single Responsibility 단일책임원칙)

한 객체는 하나의 책임을 지닌다. 어떤 클래스를 변경해야 하는 이유는, 오직 하나 뿐이어야한다.

하지만 실제 현업에서 개발하다보면, '하나의 책임' 이라는 개념이 상당히 모호하다. 어디까지를 하나의 책임으로 봐야할까? 중요한 기준은 바로 변경이다. 변경이 있을 때 어떤 파급효과가 있는지 생각하며 개발하면 SRP를 쉽게 따를 수 있다. 쉽게 말하면 클래스당 책임을 하나로 정해서, 나중에 변경하더라도 다른 곳의 파급효과가 최대한 적도록 만들어라는 말이다.

모듈화하여 하나의 객체가 한 책임만 지니도록 만든다.

우리가 네트워크 서비스를 만들 때, 어떤 비즈니스 서비스를 구현하던 항상 앞뒤로 반복되는 설정이 있다. 이를 Cross-Cutting Concerns(공통 관심사항)이라고 한다. 이를 관심사항(Concerns)에 따라 의미있는 비즈니스 로직과 설정을 분리하고 공통된 설정을 모듈화 하는 것을 AOP(Asepct Oriented Programming), 관심지향 프로그래밍이라고 하는데, 이것도 결국 SRP 원칙이 추구하는 것과 맥락이 같다.

 

---

@ OCP (Open/closed 개방-폐쇄 원칙)

소프트웨어 엔티티(클래스,모듈,함수)는 확장에는 열려있지만, 변경에는 닫혀있어야 한다.

사실 이건 누가봐도 당연한 이야기다. 하지만 직접 구현해보면 변경을 해야 확장을 하는건데, 이게 무슨 헛소리일까?

OCP는 다형성의 활용, 즉 역할과 구현의 분리를 의미한다. 객체는 '역할'에 의존성을 가져야하지, '구현체'에 의존성을 가지면 안된다.

 

하지만 아래와 같은 상황을 생각해보자. 서비스에서 DB 인터페이스에 구현체를 메모리DB에서 JDBC로 바꾸는 코드이다.

같은 인터페이스, 다른 구현체를 사용하면 '변경'하지 않고 기능을 '확장'할 수 있는 것처럼 보인다.

 

구현체를 바로 안쓰고 위의 예제처럼 인터페이스(역할)을 사용하기 때문에 OCP를 잘 지켰다고 생각할 수도 있겠다. 그러나 위와 같이 인터페이스를 만들었다고 하더라도 서버 기능을 변경할 때 위와 같이 클라이언트(서비스) 클래스에서 의존관계, 즉 구현체 코드를 직접 바꿔야 한다.

 

위의 예제는 단순해서 쉬워보이지만, 실제 서비스에서는 클래스가 복잡하게 얽혀있어 이는 절대 쉬운 작업이 아니다. 결국 이렇게 변경할 때 마다 상관없는 다른 클래스의 코드를 살펴보고 수정 한 뒤 문제가 없는지 다시 테스트, 검증해야하면 힘들게 OCP를 구현한 의미가 없어진다. 즉 이는 OCP를 따르지 않는다고 봐야한다.

 

그래서 스프링에서는 객체를 생성하고 연관관계를 맺어주는 '설정자'를 따로 분리하여 역할(인터페이스)에 넣을 구현체, 즉 의존관계를 대신 주입해준다. 즉 클라이언트 코드의 변경없이 서버를 확장 가능하게 만드는데, 이게 어떻게 가능한지는 이는 아래의 @DIP 에서 추가로 설명하겠다.

 

---

@ LSP (Liskov substitution 리스코프 치환 원칙)

서브타입은 언제나 자신의 기반타입(base type)으로 교체해도 정상 동작해야한다.
(리스코프 치환 : Sub가 Super의 자식이라면, 아무런 수정없이 Super객체를 Sub객체로 치환해도 동작해야 한다. )

말이 어려운데, 이는 알고보면 당연한 이야기이다. 다만 단순히 Parent a = Child b 만 가능한게 아니라, 이렇게 업캐스팅하더라도 동작에 문제가 없어야한다는 말이다.

 

자동차를 생각해보자. [자동차 인터페이스]에서 제공하는 'Break' 라는 기능은 하위 클래스에서 자동차를 멈추도록 구현해야한다. 하지만 개발하다보면 [자동차 객체]에 'Break' 라는 메서드에 창문을 연다던가, 속도를 가속하는 이상한 추가 기능을 구현 할 수도 있다. 물론 해당 비유는 정신 나간 짓이지만 개발을 하다보면 인터페이스의 규약을 벗어나서 코딩하는 경우가 생기고, 그렇게 했다고 해서 컴파일 에러가 나거나 서버가 죽는건 아니니까 괜찮다고 넘겨버릴 수도 있다.

 

LSP는 단순히 '컴파일되어 동작하는 코드'를 넘어서서 인터페이스의 설계를 이해하고 인터페이스의 규약을 깨는 이상한 구현을 하지말라는 말이다. 즉 어렵게 말하면 '정확성을 깨뜨리지 않으면서, 하위 타입 인스턴스로 바꿀 수 있는 객체를 만들어라' 라는 뜻.

 

---

@ ISP (Interface segregation 인터페이스 분리 원칙)

클라이언트는 자신이 사용하지 않는 메서드에 의존관계를 맺으면 안 된다.

특정 클라이언트를 위한 인터페이스 여러 개가, 하나의 범용 인터페이스보다 낫다. 범용적이게 쓸려고 사용하지도 않는 메서드를 추가하는건 의존 관계와 결합도를 늘리는 행위이다. 필요하다면 여러개의 인터페이스로 나눠서 구현하도록 하자.

• 자동차 인터페이스 -> 운전 인터페이스, 엔진 인터페이스, 정비 인터페이스로 분리
• 사용자 클라이언트 -> 운전자 클라이언트, 탑승자 클라이언트, 정비사 클라이언트 로 분리

이렇게 범용적인 인터페이스를 여러 개로 분리해서, 인터페이스 설계를 명확하게 만든다. 그리고 객체들의 결합도를 낮춰 일부를 변경해도 서로 영향끼치지 않게 만들어서 유지보수하기 쉽게 하도록 인터페이스를 분리하라는 원칙이다. 

 

---

@ DIP (Dependency inversion 의존관계 역전의 원칙)

)해당 링크의 글이 이해가 될 때, 내용을 추가할 예정)

* 참고로 의존관계 주입(DI, Dependency Injection)은 DIP를 지키는 방법중 하나이지, DIP 자체가 아니다. [컨테이너를 이용한 의존관계 주입]은 DIP와 다형성을 제공을 포함한 여러가지 목적으로 사용된다.

추상화에 의존해야한다. 구체화에 의존하면 안된다. 구현이 아닌 인터페이스에 프로그래밍하라.

객체지향의 5원칙을 책으로 만든 로버트 C.마틴은 아래와 같이 DIP를 설명하였다.

• 고차원 모듈은 저차원 모듈에 의존하면 안된다. 이 두 모듈 모두 다른 추상화된 것에 의존해야 한다.
• 추상화된 것은 구체적인 것에 의존하면 안된다. 반대로 구체적인 것이 추상화 된 것에 의존해야 한다.
• 자주 변경되는 구현체(Concrete) 클래스에 의존하지 마라.

쉽게 이야기하면, 클라이언트 코드를 만들 때 실제 구현된 객체가 아닌 해당 객체의 인터페이스만 보고 설계하라는 말이다. 즉 실제 내부 구현을 모르더라도 인터페이스만 보고 사용할 수 있도록 만들어야 한다.

 

이는 구현과 역할의 분리, 즉 클라이언트가 역할(Role)에 의존하게 만들어야한다는 말이다. 앞에서 설명한 @OCP 코드를 다시 살펴보면 인터페이스가 아닌 실제 객체의 코드를 사용하여 DIP를 위반했기 때문에 생기는 문제라고 볼 수 있다.

DIP 위반, 근데 이 정도도 안되면 어떻게 완벽한 객체지향적 코드를 작성하나요?

사실 잘 생각해보면 역할과 구현을 분리하는 자바의 다형성만으로는 OCP, DIP를 어느정도 비슷하게 만들 수는 있어도, 실제 서비스에서 원칙을 완벽하게 지키기는 상당히 어렵다. 클라이언트의 코드의 변경을 막아버리고, 깔끔하게 부품을 갈아 끼우듯이 개발하기 위해서는 뭔가 객체지향을 도와줄 도구가 더 필요하다.

 

---

# 스프링 프레임워크의 등장

객체지향적인 코드를 만드는 개발자라면, 프로젝트의 규모가 커지고 여러가지 문제상황에 맞이하다보면 위에서 했던 고민들을 하게된다. 사실 다형성, 객체지향의 5원칙도 말만 다르지 이 방법들이 추구하는 목표는 같다.

클라이언트 코드의 변경없이, 부품을 교체하듯이 개발하는 진정한 객체지향

스프링 프레임워크는 위에서 말한 다형성 + OCP, DIP를 가능하게 지원해주는 프레임워크이다.

 

---

# 정리

• 모든 설계에 역할과 구현을 분리하자.
• 공연, 영화감독은 당장 배우나 촬영장소 캐스팅을 실패했다고 해서 영화를 만들 수 없는 건 아니다. 앱 설계도 공연을 하듯이 배역만 만들어두고, 배우는 언제든이 유연하게 변경할 수 있도록 만들어야 한다.
• 이상적으로는 모든 설계에 인터페이스를 부여하자.

하지만 인터페이스를 도입하면 '추상화 설계'라는 비용이 발생한다.

기능을 확장할 가능성이 아예 없다면, 구체 클래스를 직접 사용하고 향후 꼭 필요할 때 리펙토링해서 인터페이스를 도입하는 것도 방법이다. 이러한 것을 소프트웨어의 기술부채라고 말하기도 한다. 비즈니스가 커지면 언젠가 갚아야할 기술 부채. 

 

결국 스프링 프레임워크는, 위와 같은 원칙들을 이용하여 다형성을 구현한 객체지향적인 프로그래밍을 도와주는 도구이다.