SOLID - 좋은 객체지향 설계의 5가지 원칙
SRP (단일 책임 원칙)
- 한 클래스는 하나의 책임만 가져야 한다.
- 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것
OCP (개방-폐쇄 원칙)
- 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀있어야 한다.
- 만약 클라이언트가 구현 클래스를 직접 선택하는 경우, 구현 객체를 변경하면 클라이언트 코드를 변경해야 한다. (OCP 위반)
- 따라서 객체를 생성하고 연관관계를 맺어주는 별도의 조립, 설정자가 필요하다.
LSP (리스코프 치환 원칙)
- 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
- 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야한다는 것을 의미
ISP (인터페이스 분리 원칙)
- 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
- ISP를 지키면 인터페이스가 명확해지고 대체 가능성이 높아진다.
DIP (의존관계 역전 원칙)
- 구현 클래스에 의존하지 않고, 인터페이스에 의존해야 한다.
- 클라이언트가 인터페이스에 의존해야 유연하게 구현체를 변경할 수 있다.
스프링
- 스프링은 자바 기반의 프레임워크로 객체지향 언어가 가진 강력한 특징을 살려내는 프레임워크이다.
- 객체지향 프로그래밍은 컴퓨터 프로그램을 명령어의 목록으로 보는 시각에서 벗어나 여러 개의 독립된 단위, 즉 객체들의 모임으로 파악하는 것으로 각각의 객체는 메시지를 주고받으면서 데이터를 처리한다.
- 스프링은 다형성을 활용하여 인터페이스와 인터페이스를 구현한 클래스를 분리하여 설계함으로써, 인터페이스를 구현한 객체 인스턴스를 실행 시점에 유연하게 변경 가능하다.
- 또한 스프링은 의존성 주입과 DI 컨테이너로 OCP, DIP를 가능하게 지원하고, 클라이언트 코드의 변경없이 서버의 기능을 확장하거나 변경할 수 있다.
AppConfig
- AppConfig는 애플리케이션의 실제 동작에 필요한 구현 객체를 생성하고, 생성한 객체 인스턴스의 참조를 생성자를 통해서 연결함으로써 애플리케이션을 객체를 생성하고 구성하는 영역과 사용하는 영역을 분리해준다.
- 클라이언트 입장에서 보면 의존관계를 마치 외부에서 주입해주는 것과 같아서 의존관계 주입 또는 의존성 주입이라고 한다.
- 또한 AppConfig처럼 객체를 생성하고 관리하면서 의존관계를 연결해주는 것을 DI 컨테이너라고 한다.
// 애플리케이션 설정 정보
@Configuration
public class AppConfig {
@Bean
public MemberService memberService() {
return new MemberServiceImpl(memberRepository());
}
@Bean
public MemoryMemberRepository memberRepository() {
return new MemoryMemberRepository();
}
}
SOLID의 적용
SRP
- 이전의 클라이언트 객체는 직접 구현 객체를 생성하고 연결하고 실행하는 다양한 책임을 가지고 있었다.
- 하지만 AppConfig가 구현 객체를 생성하고 연결하는 책임을 담당하고, 클라이언트는 객체를 실행하는 책임만 담당함으로써, SRP 단일 책임 원칙을 따르면서 관심사를 분리할 수 있게 되었다.
DIP
- 기존 클라이언트 코드는 인터페이스와 구현 클레스에 함께 의존했기 때문에 새로운 정책을 개발하고 적용하려면 클라이언트 코드도 함께 변경해야 했다.
- 하지만 AppConfig가 객체 인스턴스를 대신 생성해서 클라이언트 코드에 의존관계를 주입하면서, 클라이언트 코드는 인터페이스에만 의존할 수 있게 되었다.
OCP
- AppConfig가 의존관계를 클라이언트 코드에 주입하므로, 기존 정책이 변경되더라도 클라이언트 코드는 변경하지 않아도 된다.
- 즉, 애플리케이션을 사용 영역과 구성 영역으로 나누어 소프트웨어 요소를 새롭게 확장해도 사용 영역의 변경에는 닫혀있게 된다.
IoC (제어의 역전)
- 기존 프로그램은 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성하고 연결하고 실행하는 등 프로그램의 제어 흐름을 스스로 조종했다.
- 하지만 AppConfig가 등장하면서 구현 객체는 자신의 로직을 실행하는 역할만 담당하고, 프로그램에 대한 제어 흐름에 대한 권한은 모두 AppConfig가 가지게 되었다.
- 이렇듯 프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것을 제어의 역전이라고 한다.
DI (의존관계 주입)
- 의존관계는 정적인 클래스 의존관계와 실행 시점에 결정되는 동적인 객체 (인스턴스) 의존관계 둘을 분리해서 생각할 수 있다.
정적인 클래스 의존관계
- 애플리케이션을 실행하지 않아도 클래스가 사용하는 import 코드만 보고 의존관계를 쉽게 판단할 수 있다.
- 하지만 클래스 의존관계만으로는 실제 어떤 객체가 주입될지 않 수 없다.
동적인 객체 인스턴스 의존관계
- 애플리케이션 실행 시점에 실제 생성된 객체의 참조가 연결된 의존관계
- 런타임 시 외부에서 구현 객체를 생성하고 클라이언트에 참조값을 전달해서 클라이언트와 서버의 실제 의존관계가 연결되는 것이 의존관계 주입이다.
- 의존관계 주입을 사용하면 클라이언트 코드를 변경하지 않고도 클라이언트가 호출하는 대상의 타입 인스턴스를 변경할 수 있고, 정적인 클래스 의존관계를 변경하지 않으면서 동적인 객체 의존관계를 변경할 수 있다.
'Spring > Spring' 카테고리의 다른 글
빈 생명주기와 콜백 (0) | 2022.03.03 |
---|---|
의존관계 주입 방법 (0) | 2022.03.03 |
@Bean과 @Component (0) | 2022.01.27 |
스프링 컨테이너와 컴포넌트 스캔 (0) | 2022.01.20 |
Gradle 스프링 초기 설정 (0) | 2022.01.20 |