[스프링(spring)]스프링과 객체지향(SOLID포함)

allnight5·2023년 1월 27일

목록 보기

40/62

1.다형성이 가장 중요하다

2.스프링은 다형성을 극대화해서 이용할 수 있게 도와준다.

3.스프링에서 이야기하는 제어의역전(Ioc) 의존성 주입(DI)는
다형성을 활용해서 역활과 구현을 편리하게 다룰 수 있도록 지원한다.

4.스프링을 사용하면 마치 레고 블럭 조립하듯이 공연 무대의 배우를 선택하듯이
구현을 편리하게 변경할 수 있다.

여기서 문제 꼭 인터페이스를 활용해야할까?
기능을 확장할 가능성이 없다면 굳이 사용할 필요없다.
이유는 이 인터페이스가 뭔가 보고싶을때 인터페이스로 들어갔다가 구현체로 이동해야하는 단점이 있다.
언제나 사용은 장점이 단점을 넘어설때 사용하는데 인터페이스 하나에 확장성이 없는데 하나의 구현체만 사용한다면 그냥 구체(구현체) 클래스를 직접사용하는것이좋다.
이제 나중에 리팩터링할때 확장가능성이 있다면 인터페이스를 도입하는것도 하나의 방법이다.

SOLID

클린코드로 유명한 로버트 마틴이 좋은 객체 지향 설계의 5가지 원칙의 정리
1.SRP : 단일 책임원칙(Single Responsibility principle)
2.OCP : 개방-폐쇠 원칙(Open/Closed Principle)
3.LSP : 리스코프 치환 원칙(Liskov Substitution Principle)
4.ISP : 인터페이스 분리원칙(Interface Segregation Principle)
5.DIP : 의존관계 역전원칙(Dependency Inversion Principle)

SRP : 단일 책임원칙(Single Responsibility Principle

하나의 클래스는 하나의 책임만 가져야한다.
하나의 책임이라는 것을 모호하다
- 클수있고, 작을 수 있다.
- 문맥과 상황에 따라 다르다
중요한 기준은 변경이다. 변경이 있을때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것
- UI변경, 객체의 생성과 사용분리
어려운것은 얼마나 잘게 나눌것인가 이다 너무 나누면 (클래스)많아지고 적게 나누면 가지고 있는것이 많아 파급이 커진다

OCP 개방-폐쇠 원칙(Open/Closed Principle)

소프트 웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
이런 거짓말 같은 말이? 확장을 하려면 기존코드를 변경?
다형성을 활용해보자
인테페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능을 구현
지금까지 배운역할과 구현의 분리를 생각해보자

문제점

MemberService 클라이언트가 구현 클래스를 직접선택
- MemberRepository m = new MemotryMemberRepository()//기존코드
- MemberRepository m = new JdbcMemberRepository()//변경코드
구현 객체를 변경하려면 클라이언트 코드를 변경해야한다.
분명 다형성을 사용했지만 OCP원칙을 지킬수없다.
이 문제를 어떻게 해결해야하나?
- 객체를 생성하고, 연관관계를 맺어주는 별도의 조립, 설정자가 필요하다.

LSP 리스코프 치환 원칙(Liskov Substitution Principle)

프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀수 있어야한다.
다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다는 것, 다형성을 지원하기 위한 원칙, 인터페이스를 구현한 구현체는 믿고 사용하려면, 이 원칙이 필요하다.
자동차 인터페이스의 엑셀은 앞으로 가라는 기능 , 뒤로가게 구현하면 LSP위반, 느리더라도 앞으로 가야함. 그 인터페이스 기능에 맞는 구현체를 구현해야한다.

ISP 인터페이스 분리원칙(Interface Segregation Principle)

특정 클라이언트를 위한 인터페이스 여러개가 범용 인터페이스하나보다 낫다.
자동차 인터페이스 -> 운전 인테페이스, 정비 인터페이스로 분리
사용자 클라이언트 -> 운전자 클라이언트 ,정비사 클라이언트로 분리
분리하면 정비 인터페이스 자체가 변해도 운전자 클라이언트에 영향을 주지않음
인터페이스가 명확해지고 대체 가능성이 높아진다.
참조사이트

DIP 의존관계 역전원칙(Dependency Inversion Principle

-"고수준 모듈은 저수준 모듈의 구현에 의존해서는 안 된다. 저수준 모듈이 고수준 모듈에서 정의한 추상 타입에 의존해야 한다."를 의미합니다. 이것을 아주 쉽게 말하면, "자신보다 변하기 쉬운 것에 의존하지 마라"라고 이해하시면 되겠습니다.

여기서 타이어는 저수준 모듈보다는 고수준 모듈인 자동차 입장에서 만들어지는데, 이것은 고수준 모듈이 저수준 모듈에 의존했던 상황이 역전되어 저수준 모듈이 고수준 모듈에 의존하게 된다는 것을 의미합니다. 이런 맥락에서 이 원칙의 이름이 의존 역전 원칙인 것입니다.
다만, 소스 코드의 의존은 자동차가 '타이어'를 의존하지만, 런타임에서의 객체 의존은 타이어가 아니라 하위 타이어 중 하나를 의존합니다. 따라서, 의존 역전 원칙은 런타임에서의 의존을 역전시키는 것이 아니라 소스 코드 단계에서의 의존을 역전시킨다는 것을 유의해야 합니다.
OCP에서 설명한 MemberService는 인터페이스에 의존하지만, 구현 클래스도 동시에 의존한다.
MemberService클라이언트가 구현 클래스를 직접선택
- MemberRepository m = new MemotryMemberRepository()
DIP위반