Spring Framework 특징

• Spring Triangle
  

◎ POJO(Plain Old Java Object)

• POJO(Plain Old Java Object)

  • Java Object : 자바 객체 (객체지향 프로그래밍)
  • Plain Old : Java로 생성하는 순수한 객체
  • 객체지향적인 원리에 충실하면서, 환경과 기술에 종속되지 않고 필요에 따라 재활용될 수 있는 방식으로 설계된 단순한 자바 오브젝트

• POJO 프로그래밍 기본적인 규칙

  • Java나 Java의 스펙(사양)에 정의된 것 이외에는 다른 기술이나 규약에 얽매이지 않아야 한다.

    • 특정 기술을 상속해서 코드 작성시, 요구사항이 변경되서 다른 기술로 변경하려면 코드를 전부 제거하거나 수정하여야 한다.

  • 특정 환경에 종속적이지 않아야 한다.

    • 예를 들어 갑자기 Tomcat을 사용하다가 Zetty를 사용하게 될 때에도 Java 코드에는 변경이 없어야 한다.

  • 객체 지향적 원리에 충실

    • Single Responsibity Principle
    • 책임과 역할이 각기 다른 코드를 한 클래스에 몰아넣어 덩치큰 만능 클래스를 만들고 상속과 다형성의 적용이 아닌 if/switch문으로 가득 설계된 오브젝트는 POJO라고 보기 힘들다.

• POJO 프로그래밍이 필요한 이유

  • 객체지향적인 설계를 제한없이 적용할 수 있다.(가장 중요)
  • 특정 환경이나 기술에 종속적이지 않으면 재사용 가능하고, 확장 가능한 유연한 코드를 작성할 수 있다.
  • 저수준 레벨의 기술과 환경에 종속적인 코드를 애플리케이션 코드에서 제거 함으로써 코드가 깔끔해진다.
  • 코드가 깔끔해지기 때문에 디버깅하기도 상대적으로 쉽다.
  • 특정 기술이나 환경에 종속적이지 않기 때문에 테스트 역시 단순해진다.

• POJO라는 것은 Spring Framework의 3가지 특징, IoC/DI, AOP, PSA를 통해서 달성할 수 있다

◎ IoC(Inversion of Control)/ DI(Dependency Injection)

• IoC(Inversion of Control)

  • 애플리케이션 흐름의 주도권이 뒤바뀐 것
  • 메소드나 객체의 호출작업을 개발자가 결정하는 것이 아니라, 외부(프레밍워크, ...)에서 결정되는 것을 의미

• DI(Dependency Injection)

  • 스프링이 다른 프레임워크와 차별화되어 제공하는 의존 관계 주입 기능, 객체를 직접 생성하는 게 아니라 외부에서 생성한 후 주입 시켜주는 방식
  • 모듈 간의 결합도가 낮아지고 유연성이 높아진다.

• Interface 이용

  • Interface를 사용해서 의존성을 만들면, 다른 객체로 수정이 쉬워짐
  • 가독성과 유지보수의 효율이 좋아지며, 코드의 중복을 줄일 수 있다.

• DI의 필요성 / 구현

  • 필요성 : 클래스 내부에서 생성하는 특정 의존성 객체를 잠시 바꿔야 할 때, 그 의존성 객체를 쓴 모든 Class를 수정해야 함

  • 예시 : 아직 구현되지 않은 Service를 같은 데이터만 주는 Stub으로 임시구현, 그리고 이후 Service를 구현하고 코드를 수정한다면?

  • 구현 : 인터페이스(Interface)를 사용 ( 추상화(일반화) 된 클래스에 의존, Dependency Inversion Principle )
    

  • 주입 방법

    • 스프링이 실행할 때 해준다.
    • 추가 자료 참고 (@Configuration, @Bean)

• 기존 방식과 IoC 적용 후 차이

  • 기존 방식

    1. 객체 생성
    2. 의존성 객체 생성 (클래스 내부에서 생성)
    • 특정 의존성 객체를 잠시 바꿔야 할 때, 그 의존성 객체를 쓴 모든 Class를 수정해야 함
    3. 의존성 객체 메서드 호출

  • IoC 적용 후

    1. 객체 생성
    2. 의존성 객체 주입 (제어권을 스프링에게 위임하여 스프링이 만들어 놓은 객체를 주입)
    3. 의존성 객체 메서드 호출

  • 스프링이 실행될때 모든 의존성 객체를 다 만들어주고 필요한곳에 주입시켜 줌 (Bean은 싱글턴 패턴을 가짐)

• 이전 정리 자료

◎ AOP(Aspect Oriented Programming)

• AOP(Aspect Oriented Programming)

  • 관점 지향 프로그래밍
  • 어떤 로직을 기준으로 핵심적인 관점, 부가적인 관점으로 나누어서 보고 그 관점을 기준으로 각각 모듈화함
  • 공통 기능에 대해 따로 관리함

• 관심 사항 종류

  • 핵심 관심 사항(Core concern)
    • 우리가 흔히들 말하는 비즈니스 로직, 애플리케이션의 주목적을 달성하기 위한 핵심 로직에 대한 관심사
  • 공통 관심 사항(Cross-cutting concern, 부가적인 관심 사항)
    • 애플리케이션 전반에 걸쳐 공통적으로 사용되는 기능
    • ex) 보안, 로깅, 트렌젝션, 트레이싱, 모니터링

• AOP의 필요성

  • 핵심 로직에 공통적인 기능의 코드들이 여기 저기 보이면 코드 자체가 복잡해짐
  • 버그가 발생할 가능성도 높아지고 유지 보수도 당연히 어려워짐
  • 공통 기능들에 수정이 필요하게 되면 애플리케이션 전반에 적용되어 있는 공통 기능에 해당하는 코드를 일일이 수정해야 함

• AOP의 장점

  • 코드의 간결성 유지, 코드의 재사용
    • 핵심 관심 사항과 공통 관심 사항을 나누어 작성해, 코드가 간결해지고, 공통 관심 사항을 계속 재사용 가능해짐
  • 객체 지향 설계 원칙에 맞는 코드 구현
    • 특정 객체 안에서는 한가지의 기능만을 담당해야 함 (Single Responsibility Principle)
  • 높은 응집도를 가질 수 있다.

• 이전 정리 자료

◎ PSA(Portable Service Abstraction)

• PSA 기본 개념

  • 추상화 된 상위 클래스(인터페이스)를 일관되게 바라보며 하위 클래스의 기능을 사용하는 것
    

• PSA(Portable Service Abstraction)

  • 서비스 추상화(Service Abstraction)
    • 추상화 계층을 사용하여 어떤 기술을 내부에 숨기고 개발자에게 편의성을 제공해주는 것
    • ex) @Transactional
  • Portable Service Abstraction
    • 서비스의 기능을 접근하는 방식 자체를 일관되게 유지하면서 기술 자체를 유연하게 사용할 수 있도록 하는 것
    • 따라서 구현체 자체에는 관심이 없어야 한다.

• PSA 필요성

  • 어떤 서비스를 이용하기 위한 접근 방식을 일관된 방식으로 유지함으로써 애플리케이션에서 사용하는 기술이 변경되더라도 최소한의 변경만으로 변경된 요구 사항을 반영하기 위함
  • 애플리케이션의 요구 사항 변경에 유연하게 대처 가능

◎ 참고 자료

• IoC / DI
• PSA