토비의 스프링 6 | 섹션 1, 2 요약

[Leehyoungwoo]

강의 소개

공통적인 동작 원리 이해, 애플리케이션 개발에 응용하는 방법

학습 방법

• 코드의 변화에 주목
• 리팩터링 된 코드가 주는 효과
• 스프링에 어떤식으로 적용되어 있는지
• 원칙과 디자인 패턴

PaymentService 개발

요구사항

• 해외 직구를 위한 원화 결제 준비 기능 개발
• 주문 번호, 외국 통화 종류, 외국 통화 기준 결제 금액을 전달 받아서 다음의 정보를 더해 Payment를 생성한다
  • 적용 환율
  • 원화 환산 금액
  • 원화 환산 금액 유효시간
• Pamentervice.prepare()메소드로 개발
  • Payment 오브젝트 리턴

[BigDecimal]

[Record]

[BufferedReader]

구현해보기

오브젝트와 의존관계

객체(Object)

클래스와 오브젝트

• 클래스의 인스턴스 = 오브젝트 (추상적인 것의 실체, 클래스의 실체)
  • 자바에서의 오브젝트는 클래스의 인스턴스와 배열

의존관계(Dependency)

• A → B
• 클래스 사이의 의존관계 (코드 레벨의 의존관계)
  • Client → Supplier
    • Client의 기능이 제대로 동작하려면 Supplier가 필요
    • Client가 Supplier를 사용, 호출, 생성, 인스턴스화, 전송
    • Supplier가 변경되면 Client 코드가 영향을 받는다
• 오브젝트 사이의 의존관계 (런타임 환경에서 의존관계가 만들어짐)
• 클래스 사이의 의존관계와 오브젝트 사이의 의존관계가 다를 수가 있음

코드의 개선

• 기능의 개선
• 구조의 개선(리팩토링)

관심사의 분리(Separation of Concerns(SOC))

• 변경의 이유와 변경의 시점이 다른 코드를 분리
  • 사용자 인터페이스(UI)와 비즈니스 로직은 서로 다른 이유로 변경될 수 있음
  • 데이터베이스 스키마는 새로운 기능이 추가될 때마다 변경될 수 있지만, 애플리케이션의 보안 로직은 보안 취약점이 발견될 때만 수정될 수 있음
  • 구현 방법
    • 레이어드 아키텍처(Layered Architecture)
      • Repository(데이터 엑세스 레이어), Service(비즈니스 로직 레이어), Controller(프레젠테이션 레이어)
    • 객체지향 설계(Object-Oriented Design)
      • 클래스와 객체를 사용하여 각 객체가 특정 책임을 갖도록 설계
    • 모듈화(Modularization)
      • 각 기능을 독립적인 모듈로 분리
    • 서비스 지향 아키텍처(Service-Oriented Architecture, SOA)
    • 마이크로서비스 아키텍처(Microservices Architecture)

상속을 통한 확장

• 상속을 통해 유연한 확장을 하는 디자인 패턴
  • 템플릿 메서드 패턴
    • 상위 클래스에서 알고리즘의 골격을 정의하고, 하위 클래스에서 알고리즘의 특정 단계를 재정의할 수 있게 해주는 패턴
    • 구조
      • 상위 클래스에서 알고리즘의 골격을 정의하는 템플릿 메서드를 구현
      • 템플릿 메서드 내에서 추상 메서드나 훅 메서드를 호출
      • 하위 클래스에서 추상 메서드나 훅 메서드를 구현하여 알고리즘을 확장
  • 팩토리 메서드 패턴
    • 객체 생성 과정을 서브클래스로 캡슐화하여, 객체 생성 로직을 유연하게 확장할 수 있게 해주는 패턴
    • 구조
      • 상위 클래스에서 객체 생성을 위한 인터페이스를 정의
      • 하위 클래스에서 구체적인 객체 생성 로직을 구현
• 한계 존재
  • 강한 결합도로 과도한 사용은 유지보수성을 저하
  • 하위 클래스가 상위 클래스의 모든 기능을 제대로 구현하지 않으면 리스코프 치환 원칙을 위반
  • 상속은 수직적 확장에 적합하지만, 수평적 확장에는 적합하지 않을 수 있음

관계 설정 책임의 분리

원칙과 패턴

개방 폐쇄 원칙(OCP: Open-Closed Principle)

• 클래스나 모듈은 확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다.
  • ‘기능’을 확장할 때, ‘코드’는 변경되면 안된다

높은 응집도와 낮은 결합도

• 응집도가 높다는 것은 하나의 모듈이 하나의 책임 또는 관심사에 집중되어있다는 뜻
• 변화가 일어날 때 해당 모듈에서 변하는 부분이 크다
• 책임과 관심사가 다른 모듈과는 낮은 결합도, 즉 느슨하게 연결된 형태를 유지하는 것이 바람직

전략 패턴

자신의 기능 맥락에서 필요에 따라서 변경이 필요한 알고리즘을 인터페이스를 통해 통째로 외부로 분리시키고, 이를 구현한 구체적인 알고리즘 클래스를 필요에 따라 바꿔서 사용할 수 있게 하는 디자인 패턴

제어의 역전(IOC : Inversion Of Contorl)

• 제어권 이전을 통한 제어관계 역전 - 프레임워크의 기본 동작 원리

스프링 컨테이너와 의존관계 주입 (Dependency Injection)

싱글톤 레지스트리(Singleton Registry)

• Spring에서 @Configuration 어노테이션이 붙은 클래스는 싱글톤 레지스트리(Singleton Registry)로 동작 - 프록시

DI와 디자인 패턴

• Class 패턴 : 상속
• Object 패턴 : 합성
• 오브젝트 합성을 이용하는 디자인 패턴을 적용할 때 스프링 의존관계 주입을 사용
• 환율 정보가 필요할 때 매번 Web API를 호출해야 할까?
  • 환율 정보가 필요한 기능 증가
  • 응답 시간
  • 환율 변동 주기
• → 환율 정보 캐시(Cache)의 도입

WebApiExRateProvider에 캐시 기능을 추가라혀면?

• WebApiExRateProvider 코드 수정
  • → 데코레이터 디자인 패턴
    • 오브젝트에 부가적인 기능/책임을 동적으로 부여
  • 프록시와 데코레이터 차이

의존성 역전 원칙 (Dependency Inversion Principle)

• 상위 수준의 모듈은 하위 수준의 모듈에 의존해서는 안 된다. 둘 모두 추상화에 의존해야 한다.
  • 인터페이스 소유권의 역전이 필요
    • Separated Interface 패턴
• 추상화는 구체적인 사항에 의존해서는 안된다. 구체적인 사항은 추상화에 의존해야 한다.

[all-cloudz]

섹션1. 스프링 시작하기

• 스프링 개발 환경 설정
  • HTTPie는 잘 쓸 줄 알면 도움 많이 되는 것 같음
  • SDKMAN: 자바 환경 관리 툴, 많이 유용할 듯? 파이썬처럼 가상 환경 분리를 할 일이 없는데 이런거로 프로젝트별로 자바 환경 분리하는 건 좋은 거 같음
• 환율 관련 서비스 요구사항 개발
  • URL과 Connection을 획득하여 개발하는 부분은 처음 보는 거라 참 어색하고 신기함. 그런데 RestClient로 바꿀 수 있지 않을까?
  • 나머지 개발은 기본적이었음, 지금 작성한 코드를 OOP 원칙을 적용하여 개선하는 작업을 할 것 같음

섹션2. 오브젝트와 의존 관계

• 클래스 vs 오브젝트 : 오브젝트는 클래스의 인스턴스
• 개발하면서 고민한 것들
  • 관심사의 분리
    • 분리는 뭐지?
      • 하나의 메서드는 하나의 관심사만 ⇒ 메서드 분리
      • 하나의 클래스는 하나의 관심사만 ⇒ 클래스 분리
    • 관심사가 뭐지?
      • 변경의 사유가 다르다면 다른 관심사
      • 내가 개발하는 시나리오 상에서 코드들이 동일한 라이프 사이클을 갖는다면 같는 관심사로 볼 수 있을 듯?
  • 상속을 통한 확장
    • 메서드 분리 후 해당 메서드 구현 부분만 교체해서 쓰고 싶을 때 유용 ⇒ 템플릿 메서드 패턴
    • 상속이 가진 문제
      • 그런데 교체해서 쓰고 싶은 메서드가 많으면 어떡하지? 상속 받을 때 자기가 필요한 메서드만 구현할 수가 없기 때문에 이럴 때 상속은 별로 유용하지 않음
      • 자바에서는 다중 상속을 지원하지 않기 때문에 여러 곳에서 제공되는 메서드의 다양한 조합을 한 번에 해결할 수 없음
      • 부모 클래스의 변경이 모든 자식 클래스에게 영향을 줌, 부모 클래스와 자식 클래스가 강하게 결합될 가능성이 있음
      • 상속의 깊이가 깊어지거나 다중 상속을 사용하면 클래스 계층 구조가 복잡해져서 코드를 읽기가 너무 어려워짐
  • 클래스 분리 (합성) + 인터페이스 도입
    • 상속은 하지 않으면서 상속과 같은 방식으로 코드 구현 가능
    • 클래스 분리만 하면 중구난방으로 개발될 수 있으므로 인터페이스를 도입하여 유연한 설계와 다형성을 지킬 수 있음
    • 하지만! 아직도 완벽하게 유연하지 않음. 인스턴스 생성을 어디서 하는지가 중요. 클래스 다이어그램이 아니라 오브젝트(인스턴스) 다이어그램을 그려보면 문제가 더 여실히 드러남 ⇒ 런타임 의존 관계를 설정하는 책임을 다른 클래스에 주자!
  • 지금까지 고민하면서 지킨 원칙 또는 패턴은?
    • 개방 폐쇄 원칙
    • 의존 역전 원칙(DIP)
      • Policy Layer (상위) + Mechanism Layer (하위) ⇒ 상위 레이어는 하위 레이어에 의존하지 않아야 하고, 이를 위해 추상화를 도입!
      • 인터페이스는 상위 레이어, 하위의 구체 클래스는 상위 레이어에 의존해서 구현하는 거!!
      • 모듈은 자바에서는 패키지라고 생각하면 얼추 맞는듯? ⇒ 레이어를 분리했다는건 인터페이스와 그 구현을 다른 패키지에 위치시킨다는 의미
    • 높은 응집도와 낮은 결합도
    • (거의) 전략 패턴
    • (코드 레벨의) 제어의 역전과 의존성 주입
• 이제 스프링을 보자
  • 런타임에 의존 관계를 주입하는 책임을 스프링 컨테이너가 갖도록 분리함
  • BeanFactory는 내가 구성한 Bean 정보 및 의존 관계 정보를 받아서 미리 클라이언트가 사용할 오브젝트를 생성해서 보관함(컨테이너!)
  • 스프링은 별 다른 옵션이 없다면 빈을 싱글톤으로 생성함 ⇒ 싱글톤 레지스트리
• 캐시 기능을 추가해보자
  • 데코레이터 패턴 vs 프록시 패턴