객체 지향 설계와 스프링

스프링 핵심 원리 - 기본편 수강 후 정리한 포스팅입니다.

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

 

 

1. 스프링이란

 

스프링의 핵심 특징

1. 자바 언어 기반의 프레임워크

2. 자바의 큰 특징: 객체 지향 언어

3. 즉 객체 지향 언어가 가진 강력한 특징을 살려낼 수 있는 프레임워크 : Spring

4. 정리하자면, 좋은 객체 지향 애플리케이션을 개발할 수 있도록 도와주는 프레임워크

 

 

좋은 객체 지향 프로그래밍이란?

 

1. 객체 지향의 정의 : 현실세계를 코드로 반영하여, 프로그램 구현에 필요한 객체(ex 현실의 사물, etc)를 파악하고 객체간의 역할에 맞는 상호작용을 통해 프로그램을 만드는 것

2. 유연하고 변경이 용이함 => 다형성(polymorphism)

 

 

다형성의 실세계 비유

 

1. 자동차가 바뀌어도 운전자는 여전히 운전을 할 수 있다. 

2. 운전자는 자동차라는 역할(인터페이스) 에만 집중/의존하고 있다. 운전자는 자동차 내부 구조를 몰라도, 서로 다른 종류의 자동차를 운전할 수 있다.

3. 클라이언트에게 영향을 주지않고 새로운 기능을 구현할 수 있다.

4. 새로운 자동차가 나와도 *클라이언트는 아무 문제가 없다.  => 이것이 유연하고 변경 용이하다는 뜻

 

* 클라이언트 : 클라이언트 : 호출, 서버 : 응답  ➡️ 호출되는 코드를 서버코드라고 하면, 서버 코드를 호출하는 모든 코드(객체, 클래스) 가 클라이언트이다.

 

역할과 구현을 분리

 

역할과 구현으로 구분하면 세상이 단순해지고, 유연해지며 변경도 편리해진다.

• 장점
  • 클라이언트는
    •  대상의 역할(인터페이스)만 알면 된다.
    • 구현 대상의 내부 구조를 몰라도 된다.(자동차 구조)
    • 구현 대상의 내부 구조가 변경되어도 영향 받지 않는다.
    • 구현 대상 자체를 변경해도 영향을 받지 않는다.

 

자바 언어의 다형성을 활용

• 역할 = 인터페이스
• 구현 = 인터페이스를 구현한 클래스, 구현 객체 
• 중요한 점은, 객체 설계시 역할을 먼저 부여하고, 그 역할을 수행하는 구현 객체 만들 것.

 

객체의 협력이라는 관계부터 생각

• 혼자있는 객체는 없다.
• 클라이언트: 요청, 서버: 응답 이며, 수많은 객체 클라이언트와 서버는 협력 관계를 가진다.

 

자바 언어의 다형성

• 오버라이딩 => 오버라이드 된 메서드가 실행된다.
• 다형성으로 인터페이스를 구현한 객체를 실행 시점에 유연하게 변경할 수 있다.
• 클라이언트를 변경하지 않고, 서버의 구현을 유연하게 변경할 수 있다. (JDBC <=> MemoryRepository)
  • ex) 기존에 jDBC에 저장하던 데이터를 MemoryRepository 에도 저장해야할 때, 비즈니스로직을 변경하지 않아도, 유연하게 DB 를 교체할 수 있다 (유연성)

 

스프링과 객체 지향

•  객체 지향의 꽃은 다형성!
•  스프링은 다형성을 극대화할 수 있게 도와주기에, 레고 블럭 조립하듯이 객체간의 관계를 유연하게 설계할 수 있다.
•  SOLID 라는 개념을 알아야한다. 

 

---

 

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

SOLID: 좋은 객체 지향 설계의 5가지 원칙

 

SRP: Single Responsibility Principle

• 하나의 클래스는 하나의 책임만 가진다.
• 하지만 하나의 책임이라는 뜻은 모호하다
  • 책임이 클 수도 있고, 작을 수도 있다.
  • 문맥과 상황에 따라 책임은 달라질 수 있다.
• 변경이 있을 때 파급효과가 적으면 단일 책임 원칙을 잘 따른 것.
• 너무 크지도, 작지도 않도록 적절히 책임을 규정하는게 객체지향 설계의 묘미

 

OCP: Open/Closed Principle

• 소프트웨어 요소는 확장에는 열려있으나, 변경에는 닫혀있어야한다.
• 역할과 구현의 분리를 생각해보자. 
  
  

아래 코드는, 변경하기 위해 주석 처리하고 새로운 코드를 작성해야한다 (변경에 닫혀있지 않은 상태 = 변경에 열려있다 = 클라이언트 코드를 직접 변경해야한다.)

public class MemberServiceImpl implements MemberService{

    // 기존
//    private final MemberRepository memberRepository = new MemoryMemberRepository();

    // 변경
    private final MemberRepository memberRepository = new JdbcMemberRepository();
    
    ...
}

 

분명 다형성을 사용했지만, OCP 원칙을 지킬 수 없다. (<= 구현 객체를 변경하려면, 기존 코드를 변경해야한다.)

객체를 생성하고, 연관관계를 맺어주는 별도의 조립, 설정자가 필요하다. => 이 역할을 스프링이 해준다. (후에 배울 AppConfig 클래스의 역할)

 

 

LSP: Liskov Substitution Principle

• ex) 자동차의 엑셀 인터페이스는 전진 기능을 가지며, 이를 뒤로 가게 구현하면 LSP 위반하는 것이다. (느리더라도 앞으로 가야한다.)
• 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야한다.

 

ISP: Interface Segregation Principle

• 특정 클라이언트를 위한 인터페이스 여러개가 범용 인터페이스 하나보다 낫다.
• (= 인터페이스를 여러개 설계해라 = 하나의 일반화된 인터페이스가 아닌 목적에 맞는 여러개의 인터페이스를 만들어라)
• 하나의 거대한 인터페이스 보다, 하위의 여러 인터페이스를 잘 정의하여 생성하는 것이 낫다는 뜻.
• 자동차 인터페이스 ==> 운전 인터페이스, 정비 인터페이스
• 사용자 클라이언트 ==> 운전자 클라이언트, 정비사 클라이언트
• 분리하면 정비 인터페이스 자체가 변해도, 운전자 클라이언트에 영향을 주지 않음
• 인터페이스가 명확해지고, 대체 가능성이 높아진다.

 

DIP: Dependency Inversion Principle (의존성 '역전' 원칙, Dependency 'Injection' 이 아니다!)

• 프로그래머는 '추상화에 의존해야지, 구체화에 의존하면 안된다.' ( = 역할에 의존해야지, 구현에 의존하면 안된다.)
• 의존성 주입(DI)은 이 원칙을 따르는 방법 중 하나, (DI 와 DIP 는 별개)
• 클래스에 의존하지 말고, 인터페이스에 의존하라는 뜻
• 즉 역할에 의존해야 한다. (역할 = 인터페이스)

 

public class MemberServiceImpl implements MemberService{

    // 기존
//    private final MemberRepository memberRepository = new MemoryMemberRepository();

    // 변경
    private final MemberRepository memberRepository = new JdbcMemberRepository();
    
    ...
}

 

위 코드 역시 결국, 인터페이스 뿐만 아니라 구현 클래스도 동시에 의존 하는 상태이다 (DIP 위반) => MemoryMemberRepository(), JdbcMemberRepository()

 

객체 지향의 핵심은 다형성이지만, 다형성만으로는 쉽게 부품 갈아끼듯 개발할 수 없다.

다형성 만으로는 OCP, DIP 를 지킬 수 없기 때문에 다른 장치가 더 필요하다 => 스프링

 

---

 

 

3. 객체 지향 설계와 스프링

스프링은 아래 기술을 사용함으로 다형성 + OCP, DIP 를 가능하게 지원한다.

• DI (Dependency Injection) : 의존관계, 의존성 주입
• DI 컨테이너

그리하여 클라이언트 코드 변경없이 기능을 확장할 수 있고, 부품 교체하듯 개발할 수 있다.

 

정리

• 모든 설계에 역할과 구현을 분리하자.
• 공연을 설계하듯, 배역만 만들어두고 배우는 언제든지 유연하게 변경할 수 있도록 만드는 것이 좋은 객체지향 설계.
• 이상적으로는 모든 설계에 인터페이스를 부여하는 것이 좋다.

실무 고민

• 인터페이스를 도입하면 추상화라는 비용이 발생 => 개발자가 인터페이스를 한번 더 타고 들어가야한다. (일종의 단점)
• 기능을 확장할 가능성이 없다면 구체 클래스를 바로 사용한다.
• 향후 꼭 필요할 때 리팩터링하여 인터페이스를 도입하는 것도 방법이다.
• 즉, 모든 기능에 무작정 인터페이스를 도입할 것이 아니라, 상황을 보고 추상화를 할 것인지 파악해야한다.