프레임워크
프레임워크란 뼈대이다. 우리가 만들고 싶은 프로젝트의 뼈대부터 우리가 모두 만들게 된다면, 매우 시간이 오래걸리며 번거로울것이다. 그래서 선배 개발자들이 프레임워크라는 아주 좋은 기반을 다져주셨다.
덕분에 애플리케이션의 핵심 로직을 개발하는 것에 집중할 수 있도록 해주셨다.
라이브러리와 프레임워크
한번 집고 넘어가야할 라이브러리와 프레임워크의 차이점!
결론적으로 라이브러리와 목적이 프레임워크는 다르다. 라이브러리는 집을 지을때 가구에 해당된다면, 프레임워크는 방이라고 생각하면 편하다. 이미 정해진 구조와 형태! 하지만, 라이브러리는 우리의 입맛대로 사용할수있다.
즉, 라이브러리는 애플리케이션 흐름의 주도권이 개발자에게 있는 것이고, 프레임워크는 애플리케이션 흐름의 주도권이 개발자가 아닌 프레임워크에게 있는 것이다.
Spring의 특징
pojo
스프링을 제대로 사용하려면 pojo에 대해 알아야한다. pojo란 plain old java object의 약어로 말그래도 자바로 생성하는 순수한 객체의 의미를 담고있다.
pojo의 특징으로 2가지가 있다.
- Java나 Java의 스펙(사양)에 정의된 것 이외에는 다른 기술이나 규약에 얽매이지 않아야 한다.
- 특정환경에 종속적이지 않아야 한다.
위 두가지 특징의 궁극적 목표는 코드의 재활용성과 유지보수를 더 용이하게 하기위함이 있다.
위 그림을 보면 pojo를 둘러싸고 있는 3면이 있는데 무엇인지 알아보자.
Ioc / Di
ioc (제어의 역전) di(의존성 주입) 즉, Inversion of Control / Dependency Injection
Ioc의 의미하는 바는 이제 주도권은 Spring에게 역전되었다란 의미이다. 이전에는 코드를 종료시키고 말지는 개발자에게 달려있었지만, di(의존성 주입)을 통해서 이제는 프레임워크가 클라이언트에게 요청을 받을때 마다 프레임워크가 직접 실행시켜주기 때문에 main()메서드도 필요없고 이제 애플리케이션의 주도권은 프레임워크에게 있음을 알게해주는 단어이다.
Di의 의미하는 바는 그래서 ioc를 어떻게 하게 만들건데의 답이다.
의존성을 주입한다?! 아직은 잘 모르겠지만, 결론적으로는 생성자에 파라미터값으로 다른 객체를 집어넣어서 객체가 느슨한 결합을 하게 만드는 것이다. 주목적은 코드의 유지보수를 위함이다.
일반적인 Di의 모델은 인터페이스를 이용하여 코드를 작성하여 추후 변경 추가에 용이하게 만든다.
Aop
Aop(Acepted Oriented Programming) 관심지향 프로그래밍이다.
이전 OOP에 대해 들었을때는 객체지향 프로그래밍을 배웠지만, 스프링은 플러스 AOP의 원칙또한 지켜주어야 한다.
아래 사진을 먼저 확인하자.
사진을 보면 핵심 관심사항은 좌측3개 공통 관심 사항은 상단 3개가 있다.
설명하고자 하는 것은 공통 관심 사항의 설계를 따로하여 코드의 중복을 제거하자이다. 핵심사항에 대한 코드를 각각 작성하면서 공통적으로 들어가야하는 사항들을 따로 구분하여 객체 지향 설계 원칙에 맞는 코드를 구현한다.
이것이 전부이다.
Psa
psa(Portable Service Abstraction) 일괄된 서비스 추상화이다.
클라이언트가 추상화 된 상위 클래스를 일관되게 바라보며 하위 클래스의 기능을 사용하는것!
쉽게 풀어서 말하자면, 이전에 배웠던 인터페이스를 이용하여 클라이언트는 인터페이스를 사용하고 우리는 각각 사용가능한 기술에 맞게 인터페이스를 구현하는 것이다. 즉, 어떤 서비스를 이용하기 위한 접근 방식을 일관된 방식으로 유지함으로써 애플리케이션에서 사용하는 기술이 변경되더라도 최소한의 변경만으로 변경된 요구 사항을 반영하기 위함이다.
정리
POJO... 처음듣지만, 내용을 한번 보게 되면 POJO가 원하는건 손에 꼽는다.
1. 코드의 중복제거
2. 코드의 재활용성
3. 유연한 유지보수
위 원칙을 통해 더욱 효율적인 개발을 통해 궁극적으로는 시간과 돈을 아낄수있게 되는것이다.
초반에는 생각해야할 것들이 산더미겠지만, 힘들더라도 습관을 들이다 보면 나도 모르게 POJO의 개발 원칙을 지키고있을 것이다.
