SOLID 객체지향 - 스프링

스프링은 좋은 객체지향 어플리케이션을 개발할 수 있게 도와주는 프레임워크다.

 

객체지향의 프로그래밍은 객체들의 모임으로 볼 수 있으며 이 객체들은 서로 메세지를 주고받고 데이터를 처리할 수 있다. 또한 프로그램을 유연하고 변경이 용이하게 만들 수 있다.

 

1. 객체지향의 다형성

프로그램이 유연하고 변경이 용이하다는 것은 레고 블럭을 조립하는 것과 비슷하다.

자신이 원하는 기능이나 정책을 상황에 따라 다른 기능에 대한 코드에 영향없이 변경할 수 있다.

 

다형성에 대한 이해가 쉽도록 다형성을 실세계에 비유해 보자.

위 그림은 연극의 주인공의 역할과 그 역할을 누가 연기(구현)할 것인지 연기자로 구분하였다.

로미오는 줄리엣을 누가 연기하는지는 중요하지 않기 때문에 줄리엣 역할을 연기(구현)하는 연기자를 상황에 따라 변경이 가능하다. 반대로 줄리엣 또한 로미오 역할의 연기자가 바뀌어도 상관없다.

이 처럼 역할과 구현을 구분하여 설계하면 언제든지 구현체를 변경할 수 있기 때문에 프로그램이 유연해지고 확장이 가능해진다.

 

다형성을 위해 자바에서는

역할 - 인터페이스

구현 - 인터페이스를 구현한 클래스, 구현 객체 로 설계할 수 있다.

 

2. SOLID - 좋은 객체 지향 설계의 5가지 원칙

1. SRP : 단일 책임의 원칙
2. OCP : 개방-폐쇄의 원칙
3. LSP : 리스코프 치환 원칙
4. ISP : 인터페이스 분리 원칙
5. DIP : 의존관계 역전 원칙

SRP - 한 클래스는 하나의 책임만 가져야 한다. 하지만 실제 실무와 문맥 상황에 따라 해석이 다르고 복잡하기 때문에 완벽히 하나의 책임만을 가질 순 없다. 때문에 중요한 것은 변경이 일어 났을 때 파급효과의 정도이다. 파급효과가 적다면 단일 책임의 원칙(SRP)를 잘 따른 것이라고 볼 수 있다.

 

OCP - 확장에는 열려 있으나 변경에는 닫혀 있어야 한다. → 다형성 활용

기존 코드에 변경이 일어나지 않도록 다형성을 활용하여 인터페이스를 구현한 새로운 클래스를 만들었다.

그럼에도 불구하고 위 코드처럼 (//주석처리) 제거 변경이 일었났다. 다형성을 활용하였지만 어쩔 수 없이 기존 코드에 변경이 일었났다.

이 문제를 어떻게 해결할까?

문제를 해결하기 위해서는 객체를 생성하고, 연관관계를 맺어주는 별도의 조립, 설정자가 필요하기 때문에 스프링에서는 별도의 Annotation 또는 Config파일 등을 지원하여 해결한다.

 

LSP - 하위 클래스는 인터페이스 규약을 다 지켜야 한다. 예를 들어 자동차의 엑셀 기능은 앞으로 가는 것이다. 하지만 엑셀을 밝았을 경우 뒤로 가도록 구현하게 된다면 자동차의 정확성를 깨뜨리는 것이다.

프로그램 컴파일 시점에 오류가 나진 않겠지만 인터페이스를 구현한 구현체를 믿고 사용하려면 LSP 원칙을 위반해선 안된다.

 

 

ISP - 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.

자동차에 대한 클라이언트가 운전자, 정비사가 있다면 인터페이스를 자동차라는 한 인터페이스로 구성할 것이 아니라 운전자, 정비사로 나누어 여러 인터페이스로 구성하는 것이 올바르다. ISP를 따른다면 정비 인터페이스 자체가 변해도 운전자 인터페이스에는 영향이 없으며 인터페이스가 명확해지고 대체 가능성이 높아진다.

 

DIP - 구현클래스에 의존하지말고 인터페이스에 의존해라. 의존성 주입에 대한 이야기이다.

예를 들어 MemberService 클라이언트 구현 클래스를 선택할 때

MemerRepository m = new MemoryMemberRepository(); 처럼 코딩한다면 Service는 MemberRepository 인터페이스 뿐만 아니라 MemoryMemberRepository 또한 의존하게 된다.

그렇다면 어떻게 의존성 주입을 해야할까?

이 또한 스프링은 Annotation 또는 Config 파일에 빈 등록을 통해 해결하였다.