스프링 부트
앞선 포스팅에서 언급한바와 같이 스프링은 Tomcat 웹 서버를 내장하고 있다.
Tomcat 은 서블릿 컨테이너 역할도 함께 사용하고 있고, 우리는 비즈니스 로직에 좀 더 집중한 설계를 할 수 있게 된다.
스프링 부트는 스프링을 한번 더 감싼 것으로 언급이 많이 되어 있다. 구체적으로 (1) 손 쉬운 빌드 구성을 위한 starter 종속성을 제공해주고 (2) 외부 라이브러리를 버전에 알맞게 가져다 주고 (3) 매트릭, 모니터링 등을 기본적으로 제공해준다. 내부적으로는 스프링 프레임워크인 것에는 변화가 없으니 이 정도만 이해하고 있자.
다형성 (Polymorphsm)
자바는 다형성이라는 특징을 가지고 있다. 언어적인 측면에서는 선언부에 선언한 인터페이스 타입을 이용해서 다양한 클래스 오브젝트들을 다룰 수 있게 해준다는 특징을 가지고 있다. 개발과정에서는 변경과 수정이 용이해지는 장점을 가지고 있다. 즉 클라이언트는 인터페이스에서 선언한 메서드들 정보를 토대로 다양한 클래스들을 다룰 수 있게 해줌으로써 의존성의 역전을 가능하게 해준다. 클라이언트는 이를 통해 내부 구조가 변화가 되어도 컴파일 & 런타임 환경에서도 영향을 받지 않는다.
자바에서는 오버라이딩 된 구현 클래스를 이용해서 클라이언트를 변경하지 않고도 서버의 기능을 런타임에서 활용가능하게 만들어준다. 결국은 인터페이스 설계가 중요하다는 것이다.
SOLID
객체지향설계의 기본이 되는 솔리드 원칙은 구글링만해도 수백개 이상의 포스팅이 존재한다. 따라서 간략하게만 적도록 하겠다.
SRP Single Responsibility principle
하나의 클래스는 하나의 책임을 가져야한다. 중요한 기준은 변경이 된다. 변경이 생길 때 파급 효과가 적다면 단일 책임원칙을 아주 잘 준수한 것이다.
OCP Open/Closed principle
소프트웨어 요소는 확장에는 열려있고, 변경에는 닫혀있어야 한다. 인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능을 구현하고 활용할 수 있다. 객체를 생성하고 연관관계를 맺어주는 별도의 조립이나 설정자가 필요하다(DI, IoC 를 위한 Container 가 필요하다)
LSP Liskov Substitution principle
프로그램의 객체는 프로그램 활용에는 영향을 주지 않으면서, 하위 타입의 인스턴스로 바꿀 수 있어야 한다. 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야한다. 예를 들면 자동차 인터페이스의 엑셀의 위치를 바꾼다라는 것은 절대 있어서는 안 되고, 다른 자동차 구현체를 사용할 수 있어야 한다. (전기차라고 해서 엑셀의 위치가 바뀐다? 말도 안 된다)
ISP Interface segregation principle
특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나 보다 낫다. 즉 인터페이스를 늘리는 것이 차라리 낫다는 것이다. 자동차라는 인터페이스가 존재한다면 내부에 칵핏, 차체, 구동, 서스펜스 등 인터페이스들로 분리 할 수 있고, 우리는 다형성을 활용해서 조립 할 수 있다.
DIP Dependency Inversion principle
추상화에 의존해서 의존성 역전을 해야 된다. 즉 우리는 추상화에 의존하지, 구체화 클래스에 의존하면 안 된다.
