[Spring][Kotlin] 좋은 객체지향 설계 5가지 원칙 SOLID와 스프링

클린코드로 유명한 로버트 마틴은 좋은 객체지향 설계의 5가지 원칙을 정리하였다.

 

1. SRP 단일 책임 원칙 Single Responsibility Principle

 : 한 클래스는 하나의 책임만 가져야 한다.

변경이 있을 때 파급이 적으면 SRP 잘 따른 것이다.

 

2. OCP 개방 - 폐쇄 원칙 Open/Close Principle

 : 확장에는 열려 있으나 변경에는 닫혀 있어야한다.(다형성 활용)(중요함)

그러나

Problem] 클라이언트가 구현체 선택하는 과정에서 코드 변경을 해야한다.

class MemberService{
...
	//val memberRepository: MemberRepository = MemoryMemberRepository()
    val memberRepository: MemberRepository = JdbcMemberRepository()
...

}

위 처럼 MemberService가 MemberRepository 객체를 프로퍼티로 가지고 있고 memberRepository는 그 구현체인 MemoryMemberRepository였다.

그런데 구현체를 JdbcMemberRepository로 바꾸고싶다고 하면 MemberService 내부에서 위처럼 코드 변경이 있어야 한다.

Sol) 객체를 생성하고 연관관계를 맺어주는 별도의 설정자가 필요하다.

-> 이게 바로 Spring의 역할!

OCP를 지키기 위해 DI, IoC가 필요한것이다.

 

3. LSP 리스코프 치환 원칙 Liskov Substitution Principle

  : 프로그램 객체는 프로그램 정확성을 깨지 않으면서 하위타입 인스턴스로 교체가능 해야한다.

ex) 자동차 인터페이스의 엑셀은 밟으면 앞으로 간다는 규약이 보장되어야함. 느리게 간다 빠르게 간다의 차이는 있긴 하겠지만 뒤로가면 LSP 위반.

 

4. ISP 인터페이스 분리 원칙 Interface Segregation Principle

 : 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.

-> 하나의 인터페이스가 변해도 다른 인터페이스에 영향을 미치지 않는다.

-> 인터페이스가 명확해지고 대체 가능성이 높아진다.

 

실제 Spring Framework에서도 인터페이스들은 철저하게 분리되어 있다.

 

5. DIP 의존관계 역전 원칙 Dependency Inversion Principle

 : 프로그래머는 추상화에 의존해야지 구체화에 의존하면 안된다.(중요함)

 -> 구현 클래스에 의존하지 말고 인터페이스에 의존하라.

 = 역할에 의존하고 구현에 의존하지 마라.

 

의존한다는 것은 그것에 대해 안다는 것을 의미한다.

Problem] 위의 MemberService, MemberRepository 예시로 봤을 때,

MemberService 클라이언트가 구현 클래스로 MemoryMemberRepository 선택하는 순간!

그것에 대해 알고 있기 때문에 DIP 위반

 

---

정리

객체지향의 핵심은 다형성이다.

But 다형성 만으로는 구현 객체 변경 시 클라이언트 코드도 함께 변경된다.

-> 다형성만으론 OCP, DIP 지킬 수 없다.

-> 무언가 더 필요하다.

 

스프링은 이것을 가능하게 지원해주는 기술이다.

스프링은 DI, DI 컨테이너로 다형성 + OCP + DIP를 모두 가능하게 지원해주는 기술이다.

DI 컨테이너
 : 자바 객체들을 컨테이너 안에 넣어놓고 의존 관계를 연결, 주입해주는 기술
(뒤에 포스팅에서 자세히 알아보도록 하자)

c.f] 옛날에 어떤 개발자가 객체지향 개발하려고 OCP, DIP 원칙 지키면서 개발해보니 개발 내용보다 원칙을 지키기 위한 일이 더 많았다.
-> 이를 Framework로 만들어버렸다

순수 자바로 OCP, DIP원칙 지키면서 개발하면 결국 스프링(DI 컨테이너) 만들게 된다.

 

---

이상적으로는 모든 설계에 인터페이스를 부여하는 것이 좋다.

이는 3rd party 미정시에도 개발 가능하게 한다.(하부 구현을 최대한 미룰 수 있다.)

그러나

Problem] 인터페이스 도입 시 추상화라는 비용이 발생한다.

Sol) 기능 확장 할 필요 없을 땐 구체 클래스를 사용하되, 나중에 리팩토링을 통해 인터페이스를 도입하면 된다.

 

 

 

 

[출처]

스프링 핵심 원리 - 기본편

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-%EA%B8%B0%EB%B3%B8%ED%8E%B8/dashboard

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