OOP와 스프링

OOP를 왜 사용할까?

소프트웨어의 복잡성을 제어하고 관리하기 가장 쉬운 대중적인 방법이다.

 

OOP란? 

 데이터(상태)와 로직(행위)이 응집되어 상호 교류하여 동작하도록 만드는 기법(ex) 상속, 캡슐화, 다형성)

 1. 분류  > Class

   Class는 프로그램의 코드를 체계적으로 분류하고 같은 역할을 하는 코드를 응집성 있게 모아준다. 

 2. 교체 > 유지보수 

   경우에 따라 특정 모듈을 통째로 변경해야 할 수 도 있음

 

OOP를 잘하려면?

 SOLID 원칙을 준수!

  1. SRP - 단일 책임 원칙 : 한 클래스는 단일의 책임을 가져야 한다.

    단일? 책임? 둘다 모호함  

 

  2. OCP - 개방 폐쇄의 원칙 : 확장에는 열려있고, 변경에는 닫혀있다. 

    수정하지 말고 신규 클래스를 추가하자!

 

  3. LSP - 리스코프 치환 법칙 : 서브 타입은 언제나 기반타입으로 교체할 수 있어야 한다. 

    상속받는 클래스는 부모 클래스와 동일한 동작을 해야 재활용 가능성이 높아진다. 

    실무에서는 상속을 잘 사용하지 않음 

    1. 상속 시 오버라이드를 한것과 아닌것의 혼란

    2. 상속 오버라이드를 잘못하면 로직충돌 -> Fragile base class

    3. 기능을 너무 확장하거나 변경하면 재활용성 낮아짐

Fragile base class 
부모 클래스의 변경에 의해 자식 클래스가 영향을 받는 현상
 자식 클래스를 점진적으로 추가해서 기능을 확장하는 데는 용이하지만 높은 결합도로 인해 부모 클래스를 점진적   으로 개선하는 것은 어렵게 만든다.
 자식 클래스가 부모 클래스의 구현 세부사항에 의존하도록 만들기 때문에 캡슐화를 약화 시킨다.

또 다른 상속의 문제점 
https://velog.io/@swucs/10%EC%9E%A5-%EC%83%81%EC%86%8D%EA%B3%BC-%EC%BD%94%EB%93%9C-%EC%9E%AC%EC%82%AC%EC%9A%A9

   

  4. ISP - 인터페이스 분리 원칙 : 인터페이스 또한 단일 책임을 갖도록 분리해야 한다. 

    

  5. DIP - 의존성 역전 원칙 : 하위 모듈의 변경이 상위 모들의 변경을 요구하는 의존성을 끊어 내야 한다. 

    기존 라이브러리 사용 -> 다른 라이브 러리로 변경시 강결합이라면 코드 전체를 수정해야할 수 도 있음 

 

 

 스프링과 SOLID

https://www.javaguides.net/2020/07/three-tier-three-layer-architecture-in-spring-mvc-web-application.html

1.Presentation layer: 응용프로그램의 기능과 데이터를 사용자에게 제공하는 응용프로그램의 사용자 인터페이스입니다.

 

2.Business logic (or Application) layer: 이 계층에는 애플리케이션의 핵심 기능을 주도하는 비즈니스 로직이 포함되어 있습니다. 의사 결정, 계산, 평가 및 다른 두 계층 간에 전달되는 데이터 처리와 같습니다.

 

3.Data access layer (or Data) layer: 이 계층은 데이터베이스와 상호 작용하여 응용 프로그램 데이터를 저장하고 복원합니다

 

 스프링은 표준적인 레이어 별 역할을 나눠주기 때문에 SRP를 도와줌 각 Class마다 역할이 더 명확해짐