객체지향 설계와 스프링

개요

스프링에 대해 깊게 이해를 하기 위해 기본 내용에 대하여 숙지하고자 글을 씁니다.

 

내용

객체 지향을 설명할 때 빠지지 않는 요소가 있습니다. 바로 '좋은 객체 지향을 설계할 때 지켜야 할 5가지 원칙' 인데요.

객체 지향에 대해 설명하기 전에 앞서 '객체지향 프로그래밍을 했을 때의 좋은 점이 뭐길래 이걸 알아야 하죠?' 라고 질문을 할 수 있습니다.

객체지향 프로그래밍은 객체들의 모임에서 객체끼리 메시지를 주고받고 데이터를 처리할 수 있는 개념이라고 설명할 수 있는데요, 이러한 객체지향 프로그밍은 '캡슐화', '상속', '다형성', '추상화' 의 특징을 가지고 있으며 장단점을 열거하자면 아래와 같습니다.

 

객체지향 언어의 장점

• 프로그램을 유연하고 변경이 용이하게 만들기 때문에 대규모 프로그램 개발에 많이 사용

객체지향 언어의 단점

• 개발속도가 느리며 코딩 난이도 상승 - 객체가 처리하는 것에 대한 정확한 이해 필요하므로 설계단계에서 시간 많이 소요됨

 

객체지향 프로그래밍의 가장 중요한 특성 중 하나인 다형성에 대해 간략히 설명하자면 아래와 같습니다.

 

다형성: 하나의 객체가 여러가지 타입을 가질 수 있는 성질

 

위에서 다형성을 소개하는 이유는, 다형성과 SOLID 원칙을 동시에 지켜야 하지만 둘을 위배하는 경우가 발생하여 이를 해결하기 위해 스프링이 제공하는 특별한 기능을 설명하기 위해서에요.

 

이제 설명할 내용은 SOLID 원칙 인데요, 이미 인강이나 다른 블로그 글들을 보면서 수없이 많이 봐오셨을 겁니다.

// 1. 인터페이스 (역할)
public interface ExampleRepo {
	public void example();
};

// 2. 클라이언트
public class ExService {
	ExampleRepo ex = new MyExampleRepo(); // 클라이언트(ExService)에서 직접 구현클래스를 설정
}

 

• SRP(단일 책임 원칙): 한 클래스는 하나의 책임만 가져야 한다
• OCP(개방-폐쇄 원칙): 소프트웨어 요소는 확장에는 열려있으나 변경에는 닫혀있어야 함, 즉 새로운 기능 구현시 인터페이스를 구현한 클래스를 만들고 그 구현 클래스를 통해 개발해야 함
  ex) 위 코드는 OCP를 위반하는데 구현 객체인 MyExampleRepo 를 변경하려면 클라이언트 코드 변경 필요하기 때문,  즉 별도의 설정자(DI 컨테이너)가 필요함
• LSP(리스코프 치환 원칙): 하위 클래스는 인터페이스의 규약을 다 지켜야 한다
• ISP(인터페이스 분리 원칙): 특정한 클라이언트를 위한 인터페이스 1개가 여러 개를 위한 범용 인터페이스 하나보다 낫다
• DIP(의존관계 역전 원칙): 클라이언트 코드는 구현 클래스(구현) 대신 인터페이스(역할)에 의존해야 한다
  ex) 위 코드에서 ExService 클라이언트는 ExampleRepo 의 구현클래스를 직접 설정하였는데 이는 DIP 원칙을 위반함

 

위 코드는 다형성을 기반하여 짜여진 코드이나 SOLID 를 지키지 못하는 모습을 보여줍니다.

스프링은 DI(의존관계 주입) 및 DI 컨테이너를 통해 다형성 및 OCP, DIP를 지킬 수 있게 해줍니다.

 

 

출처

인프런 스프링 핵심 원리 - 기본편 (김영한)