객체 지향 설계와 스프링

객체 지향 설계와 스프링

스프링이란

여러가지의 기술의 모음이라고 할수 있다. 스프링 데이터 : JPA, DB에 있는 기본적인 CRUD를 편리하게 사용할수 있도록 도와준다. 스프링 시큐리티 : 보안과 관련된 설정을 도와준다. 스프링 세션 : 세션에 관련된 설정을 도와준다. 스프링 배치 : 배치 처리를 도와준다. 스프링 Rest Docs : API 문서화를 편하게 해준다. ….

스프링 부트

• Tomcat과 같은 별도의 웹서버를 내장에서 별도의 웹 서버를 설치하지 않아도 된다.
• starter 라이브러리를 가져올때 starter를 사용하면 하나를 가져올때 필요한 부수적인 라이브러리를 같이 빌드한다.
• 서드파티(3rd parth) 자주사용되는 메이저 라이브러리와의 버전호환성을 관리해준다.
• 애플리케이션의 상태를 숫자 측정값으로 나타낼수 있는 메트릭, 모니터링 기능을 제공해 준다.
• 관례에 의한 모든 초기 설정이 되어있어서 특정 다른부분만 커스텀마이즈 하여 사용할수 있다.

SOLID

SRP 단일 책임 원칙

Single responsilbility principle

• 한 클래스는 하나의 책임만 가져야한다.
• 변경이 있을 때 파급효과가 적으면 단일 책임 원칙을 잘 따른 것이다.

예) UI변경, 객체의 생성과 사용을 분리

OCP 개방-폐쇄 원칙

Open/closed principle

• 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
• 다형성을 활용하면 역할과 구현을 나눌수 있다
• 인터페이스를 이용하여 역할을 정의하고 새로운 클래스를 만들어 기능을 구현한다.
• 사용하고 있는 인터페이스는 그대로 있기 때문에 기존 코드에 변경을 주지 않는다.

문제점

DI를 사용하지 않으면 클라이언트, 즉 소프트웨어가 구현 객체를 변경할려면 코드를 변경해야한다. 다형성을 사용했지만 OCP 원칙을 지킬 수 없다.

LSP 리스코프 치환 원칙

Liskov substitution principle

• 프로그램의 객체는 인터페이스 규약을 다 지켜야한다. 주문받는 역할을 하기로 했으면 주문받는 역할을 하는 객체가 있어야한다.

예) 자동차 인터페이스의 엑셀은 앞으로 가라는 기능을 한다 만약 뒤로 가게 구현한다면 LSP를 위반한 것이다. 느리더라도 앞으로 가기만 한다면 LSP를 위반하지 않는다.

ISP 인터페이스 분리 원칙

Interface segregation principle

• 여러 클라이언트를 위한 범용적인 인터페이스 보다 특정 클라이언트를 위한 인터페이스 여러개가 낫다.
• 여러가지 인터페이스로 분리하여 관리하게되면 A인터페이스를 변경하더라도 B인터페이스가 영향을 받지 않는다.

DIP 의존관계 역전 원칙

Dependency inversion principle

• 구현 클래스에 의존하지 말고 역할을 정의한 인터페이스에 의존해야한다.
• 객체 세상도 클라이언트가 인터페이스에 의존해야 구현체를 쉽게 변경할수 있다. 구현체에 의존하게 되면 수정해야 될 부분이 많아져 변경이 어려워진다.

문제점

DIP도 OCP에서 얘기 했던 것과 마찬가지로 다형성을 사용하더라도 클라이언트가 구현 클래스를 직접선택한다. 인터페이스에 의존하지만 동시에 구현클래스도 의존하게 되는 것이다. DIP 원칙을 지킬수 없다.

스프링

OCP와 DIP 원칙을 지키기 위해선 DI(Dependency Injection)를 사용할 수 있어야 한다.

• 클라이언트 코드의 변경 없이 기능 확장
• 부품을 교체하듯이 컴포넌트로 개발

정리

• 모든 설계에 역할과 구현을 분리하자
• 애플리케이션 설계도 역할만 정해두고 구현은 언제든지 다른것으로 변경할 수 있도록 만드는 것이 좋은 객체지향 설계이다.

주의할점

인터페이스를 무분별하게 사용할 경우 한번에 구현클래스를 보기가 힘들어 코드의 가독성이 떨어질수있다. 추천하는 방법으로는 변경될지 않을것 같은 클래스는 인터페이스를 설계하지 않고 추후에 리펙터링을 하는것이 좋다.