오늘의 목표
- POJO
- IOC/DI
- AOP
- PSA
내용
POJO(Plain Old Java Object)
스프링은 웹 개발에 필요한 자바 프레임워크입니다. 스프링의 핵심개념들을 POJO라고도 합니다. POJO는 IOC/DI , AOP, PSA를 모두 구현함으로써 달성할 수 있습니다.
우선 JO부터 살펴보겠습니다.
JO는 객체와 객체가 관계를 맺을 수 밖에 없는 객체지향 프로그래밍 입니다.
PO도 의미를 가지고 있습니다.
PO는 순수 자바로 생성하는 객체입니다.
Spring자체가 자바 프레임워크이니 자바로 객체를 생성한는 것은 당연한데, 순수 자바로 만드는것이 조금 의아하실수 있습니다. 이것은 특정 기술에 얽메이지 않는 객체를 생성한다는 의미입니다.
- JAVA나 JAVA의 스펙에 정의된 것 이외의 다른 기술이나 규약에 얽매이면 안됩니다.
-> 특정 기술을 사용할 수 있으나, 요구사항이 기존과 다른 기술을 요구할 때 기존의 기술에 종속적이지 않고 다른 기술을 채택할 수 있어야 합니다. - 특정 환경에 종속적이지 않아야 합니다.
-> 서버를 실행시키는 환경, 클라이언트의 환경에 상관없이 같은 결과를 도출해야 합니다.
POJO 프로그래밍 필요한 이유
- 특정 기술에 종속적이지 않고, 재사용 가능, 유연한 확장
- 코드가 간결해짐, 디버깅이 쉬워짐, 테스트가 단순해짐
- 객체지향적인 설계를 제한없이 적용할 수 있습니다.
IOC(Inversion of Control)/DI(Dependency Injection)
IOC
Framework와 Library는 개발자에게 필요한 기능을 제공한다는 점은 동일하지만, Libraray는 개발자가 애플리케이션의 흐름을 주도하고 Framewrok는 애플리케이션이 애플리케이션의 흐름을 주도하는것으로 주도권이 뒤바뀐 것을 바로 IoC(Inversion of Control)이라고 합니다.
이전까지 main()메서드의 시작부터 마지막까지 다른 메서드를 호출하거나, 반복문, 조건문등을 통해 흐름을 개발자가 주도하는것과 달리, 웹 서버는 항상 열려있고 실행 주이기 때문에 별도의 main()메서드가 존재하지 않고 웹 어플리케이션 자체가 흐름을 제어합니다.
DI
DI는 IoC 개념을 조금더 구체화 시킨 것이라고도 할 수 있습니다.
Dependency는
의존하는 또는 종속되는의 의미가 있고,Injection은주입이라는 의미를 가지고 있습니다. -> 의존성 주입
객체지향 프로그래밍에선 의존성은 객체간의 의존(한 객체가 다른 객체의 메서드를 사용)을 의미합니다. 즉, 다른 클래스의 기능을 사용 할 때, 다른 클래스에 의존한다고 말할 수 있습니다.
ex) A 클래스가 B 클래스의 메서드를 사용한다 -> A클래스는 B클레스에 의존한다
느슨한 결합
스프링에선 테스트, 디버깅, 유지보수 등을 원활히 하기 위해서 객체간의 의존도를 낮추어야 합니다.
사용하는 클래스 내부에서 new연산으로 객체를 생성하면 강한게 결합이 되니 외부에서 따로 만든 객체를 사용하는 객체에 외부에서 주입시켜 느슨하게 결합되도록 합니다.
클래스의 생성자로 객체를 전달 받는 코드가 있다면 "객체를 외부에서 주입 받고 있구나"고 생각하시면 됩니다.
더 느슨한 결합
인터페이스를 사용하여 더 느슨하게 의존성을 주입할 수도 있습니다.
자바를 공부할 때 인터페이스나 상위클래스 변수를 이용하여 업캐스팅, 동적 바인딩를 활용한 다형성을 구현해 보았었습니다. 하위클래스 객체를 상위클래스로 업캐스팅하여 메서드를 호출하면, 동적 바인딩으로 하위클래스에 오버라이딩된 메서드가 호출됩니다.
해당 객체를 가리키는 변수와 매개변수를 인터페이스로 업캐스팅한다면, 해당 클래스를 직접적으로 의존하는 것이 아니라 인터페이스를 의존하게 되므로 의존성을 더욱 더 느슨하게 만들 수 있습니다.
더더 느슨한 결합
스프링에선 Config클래스와 각종 @에노테이션을 지원합니다. 이 둘을 적절히 활용하여 개발자가 직접 클래스를 인스턴스화 시키는 것이 아닌, Spring 컨테이너에 클래스를 넣어 Spring 컨테이너가 알아서 객체를 생성하고 의존성 객체를 주입 하도록 하는 기능을 제공합니다.
개발자가 직접 NEW 연산을 사용하는 것이 아닌 Spring Framework 영역의 Config클래스에 할당하고, Config클래스는 실제 애플리케이션 핵심 로직에 관여하지 않으므로 결합을 더욱 더 느슨하게 만들 수 있습니다.
AOP(Aspect Oriented Programming)
개발을 할때 애플리케이션에 핵심적인 기능도 있을거고 핵심적이진 않지만 전반적으로 필요한 공통적으로 적용되는 공통기능도 있습니다.
- 핵심 관심 사항(Core concern) : 애플리케이션의 목적 달성을 위한 핵심 로직 (비즈니스 로직)
- 공통 관심 사항(Cross-cutting concern) : 애플리케이션 전반에 걸쳐 공통적으로 사용되는 기능
공통 관심 사항을 부가적인 관심 사항이라고도 합니다.
핵심 관심 사항은 애플리케이션내에서 각자 자기의 일을 하는 로직이 짜여져 있는 반면에 공통 관심 사항은 애플리케이션 전반적으로 공통됨을 확신 할 수 있습니다.
AOP는 애플리케이션의 핵심 업무 로직에서 공통 관 시항을 분라히는 작업 입니다.
예를들어 데이터베이스에 데이터를 저장하는 과정을 할때 데이터베이스 연결에 필요한 객체들을 어느 데이터를 얼만큼 저장하느냐와 상관없이 동일한 열고 닫기를 명령해야 합니다.
이러한 열고 닫기와 같은 공통된 작업을 생략하게 함으로써 비즈니스 로직에 집중할 수 있게 해줍니다.
AOP 필요한 이유
- 코드의 간결성 유지
- 객체 지향 설계 원칙에 맞는 코드 구현
- 코드의 재사용
PSA(Portable Service Abstraction)
객체지향 프로그래밍 언어인 자바에서 코드로 추상화를 표현할 수 있는 대표적인 방법이 추상 클래스와 인터페이스 입니다.
DI에서 언급된 업캐스팅과 동적 바인딩을 이용하여 상위 클래스나 인터페이스에서 하위클래스의 기능을 사용할 수 있게 하는것을 기억 하시나요?
추상화 된 클래스를 일관되게 바라보며 하위 클래스의 기능을 사용하는 것이 바로 일관된 서비스 추상화(PSA)의 기본 개념입니다.
코드레벨에서 클라이언트는 서버에 존재하는 클래스의 기능을 사용합니다. 이때 PSA로 구현된 기능은 업캐스팅으로 어느 요구사항이든 처리할 수 있는 서비스를 제공할 수 있어야 합니다.
예를 들어 데이터베이스에 연결하기 위해선 객체가 필요합니다. 오라클 DB를 사용하다가 몽고DB, MySQL등으로 요구사항이 변경되었을 때 똑같이 작동한다고 합시다.
다형성에 대하여 공부하였든 SQL이라는 인터페이스를 만들고 각 DB마다 인터페이스를 상속받는 클래스를 만들면 어느 DB를 사용하든 동일한 인터페이스로 접근이 가능할 것입니다.
어떤 서비스를 이용하기 위한 접근 방식을 일관된 방식으로 유지함으로써 애플리케이션에서 사용하는 기술이 변경되더라도 최소한의 변경만으로 변경된 요구 사항을 반영하기 위함입니다.
후기
오늘 드디어 처음으로 Spring을 배웠습니다. 제대로 배워야 하는 내용인지, 다른 내용과 다르게 사전에 알아두어야 할 개념부터 자세히 익히는 듯 합니다. 처음 접하는 거라 많이 어렵지만, 익숙해지면 또 괜찮을 것 같습니다.
GitHub
https://github.com/ds02168/CodeStates_Spring/tree/main/section2-week3
