[Spring] - SOLID란?

앞선 글에서

2022.08.10 - [Spring] - [Spring] Spring Framework(스프링 부트, 스프링, 프레임워크와 라이브러리 차이점, POJO)

[Spring] Spring Framework(스프링 부트, 스프링, 프레임워크와 라이브러리 차이점, POJO)

핵심적인 것은 객체 지향 언어라는 강력한 특징을 살려내는 것으로 좋은 객체 지향 어플리케이션을 개발 할 수 있게 도와주는 프레임 워크다.

라는 글을 볼 수 있을 것이다.

그러면 도대체 좋은 객체 지향 어플리케이션이 무엇인가에 대해 의문점을 가질 수 있고, 이걸 어떻게 해야하나라는 막막함이 있을 수 있다.

 

우선적으로 생각해보면, 자바에서 배웠던 객체 지향의 특징을 보면 추상화, 캡슐화, 상속, 다형성을 생각할 수 있다.

또, 위키백과를 보면, 

객체 지향 프로그래밍이라는 것은 객체들의 모임으로 파악하고자하는 것으로 각각의 객체는 메시지를 주고받고, 데이터를 처리 할 수 있다. , 프로그램을 유연하고 변경이 쉽게 만든다

라고 한다.

 

다형성 - 다른 대상으로 변환이 가능하고 앞의 새로운 구현체가 기존의 역할을 수행할 수 있는 것
예를 들기 이전에, 회사에 여러 직군들이 있을 수 있다. 나의 입장에서는 개발자이기에 개발 직군에 대해 예를 들어보겠다
개발 직군에서도 백엔드, 프론트엔드로 나뉠 수 있을 것이다. 이때 백엔드만의 역할이 있고, 프론트엔드만의 역할이 있을 것이다. 그런데 이 직군은 회사에 부합하는 능력을 가진 여러사람들이 대체할 수 있다.
이것으로 볼 때 백엔드 직군으로써 프론트엔드 직군으로써 역할이 가능하다면, 회사 대표는 해당 각 직군을 다른여러사람들로 대체 가능하다. 이것이 바로 다형성인 것이다. (즉, 역할을 변경되지않고 이 역할을 수행할 대상은 바뀌어도 된다.)
그런데 현실적으로 보면, 위의 예는 역할 내부에서 하는일들을 다 알아야한다는 특징이 있다.
다형성에서는 역할만 알면 되고 내부구조는 몰라도 된다는 것이다.
다른 예로는 키보드, 마우스가 있다.
즉, 인터페이스와 클래스를 분리.
본질은 클라이언트를 변경하지 않고, 서버의 구현 기능을 유연하게 다양한 구현체로 변경할 수 있다.

위의 내용들을 보면, 판단하기에 애매한 느낌이 든다.

그래서 좋은 객체 지향 어플리케이션으로 만드는 방법을 소개하고자한다. 이것은 바로 SOLID라는 것이다.

---

SOLID란?

로버트 마틴이 2000년대 초반에 명명한 객체 지향 프로그래밍 및 설계의 다섯 가지 기본 원칙을 마이클 페더스가 두문자어로 소개한 것

 

[SRP] - 단일 책임 원칙(Single Reposnsibility principle)

하나의 객체는 하나의 책임만을 갖는다
여기서 책임이라고 하는 것은 클 수도, 작을 수도 있기에 모호하다.
하나의 객체에 있어서 변경이 이루어졌을 경우 파급효과가 적은 경우 이 원칙을 잘 따른 것이다.
낮은 결합도, 높은 응집도를 얻기 위한 원칙이다.

예) 회원 로그인 서비스 클래스가 있다고 해보자
      위의 클래스에는 로그인에 관련된 기능이외에 회원가입에 대한 역할을 부여받는 경우 한가지의 책임을 더 받게 된다
      따라서 로그인 서비스 클래스에 회원가입을 해 회원을 저장하라는 책임을 더 부여하게 되는 것은 SRP를 위반하는
      것이다.

 

[OCP] - 개방 폐쇄 원칙(Open/Closed Principle)

다형성을 이용했을 때에는 개방되어 확장에는 열려있게하고, 역할 변경에는 닫혀있게(못하게) 하자.
기존의 코드(역할, 기능)를 변경하지 않으면서 기능을 추가할 수 있도록 설계가 되어야 한다.
변화하는 부분을 추상화하는 것이 Point이다.
이 원칙을 지키기 위해 DI, IOC 컨테이너들이 필요하다

예) 핸드폰으로 보면, 중요 역할로 메시지 보내기, 통화가 있는 것을 볼 수 있다.
                                   이 기능들을 변경하게 되면, 핸드폰이 아닌 것이 된다 그래서 변경에는 닫혀있게하자.
                                   확장에 관해서는 내가 원하는 앱을 다운받아 추가적으로 사용할 수 있는 것들로 생각해보자

 

[LSP] - 리스코프 치환 원칙(Liskov substitution principle)

상위 타입의 객체를 하위 타입의 객체로 치환해도 동작에 문제가 없어야 합니다.
즉, B가 A의 자식일 때, A 타입을 사용하는 부분에서 B로 치환해도 문제없이 원래의 A타입을 사용했던 동작(원래 동작과 반대로되서는 안됨)이 되어야 합니다. 

 

[ISP] - 인터페이스 분리 원칙(Interface segregation principle)

기능들인 메서드들을 각 하나의 인터페이스로 만드는 것이 모든 기능을 하나의 인터페이스에 가지고 있는 것보다 낫다.
클라이언트가 자신이 이용하지 않는 메서드에 의존하지 않아야 한다는 원칙 - 위키백과
즉, 많은 메서드를 가진 하나의 인터페이스를 조금 더 구체적인 하나의 메서드를 가지는 인터페이스로 쪼개는것이 낫다

 

[DIP] - 의존관계 역전 원칙(Dependency Inversion principle)

구체화된 클래스에 의존하지 않고, 추상화된 클래스(추상 클래스 또는 인터페이스)에 의존해라
즉, 구체화에 의존하지 말고, 추상화에 의존해라.
코드에서보면 구체화된 클래스를 쓰는 것이 아닌 인터페이스를 쓰라는 것이다. -> 역할에 의존해라
인터페이스에 의존하게 한다면, 해당 인터페이스를 구체화한 여러 클래스를 쓸수 있기 때문이다.

-> 생성자로써 구현하는 것을 받자. 이렇게 한다면, 코드에서는 인터페이스에 의존하게 된다.