객체 지향 설계와 스프링

좋은 객체 지향 설계란?

---

• 좋은 객체 지향를 설계하기 위해서는 역할과 구현을 분리하여 설계할 수 있어야 한다.
  • e.g. 공연을 설계할 때 배역에 대한 역할을 설계하고 배우는 언제든지 유연하게 변경할 수 있도록 만든다.
• 이를 위해 이상적으로는 인터페이스를 도입하는 것이 좋지만 추상화가 될 경우 비용이 발생하는 단점이 따라온다. 하여 기능을 확장해야 되는 케이스가 발생하지 않는다면 구체 클래스를 직접 사용하고 향후 필요 시 리팩토링을 통해 인터페이스를 도입할 수도 있다.

 

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

---

SRP(single resposibility principle)

• 한 클래스는 하나의 책임만 가져야 한다.
• 변경 상황에 따르는 파급 효과를 최소화 할 수록 SRP를 잘 지킨 것이라 할 수 있다.
  • e.g. UI 변경, 객체의 생성과 사용 분리

LSP(liskov substitution principle)

• 프로그램의 객체는 프로그램의 정확성을 깨트리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
• 다형성에서 하위 클래스는 인터페이스 규약을 지켜야 한다.
  • e.g. 자동차 인터페이스의 엑셀을 앞으로 가는 기능, 뒤로 가게 구현하면 LSP 위반

ISP(interface segregation principle)

• 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다. → 적당히 쪼갤 수 있어야 함
  • e.g. 자동차 인터페이스_운전 인터페이스, 정비 인터페이스로 분리
• ISP를 따를 경우 인터페이스가 명확해지며 대체 가능성이 높아진다.

DIP(dependency inversion principle)*

• 구체화에 의존하지 않고 추상화(역할)에 의존해야 한다.
• 클라이언트가 인터페이스에 의존해야 구현제를 유연하게 변경할 수 있다.

OCP(open/closed principle) *

• 소프트웨어 요소는 확장에는 열려있어야 하나 변경에는 닫혀있어야 한다.
• 역할과 구현을 분리하여 다형성을 활용한다.

e.g. 인터페이스를 구현한 클래스를 만들어 새로운 기능을 구현

  

    
    
    
    
  
public class MemberService{
	//private MemberRepository memberRepository = new MemoryMemberRepository();
    private MemberRepository memberRepository = new JdbcMemberRepository();
}
//기능 확장하기 위해 코드 변경 필요

• 그러나 확장을 하려면 기존 코드를 변경해야하지 않나? → OCP 원칙 지킬 수 없음
• 때문에 OCP DIP 등 객체 지향 원칙을 지키며 개발하기 위해서는 스프링의 도움이 필요하다.
  • 객체를 생성하고 연관관계를 맺어주는 별도의 조립,설정자 필요

 

스프링의 역할

---

• 스프링에서 제공하는 DI 컨테이너를 통해 클라이언트 코드의 변경 없이 기능을 확장하고 쉽게 교체 가능한 개발을 할 수 있다.
  • 다형성 + OCP,DIP 가능하도록 지원