Chapter 02. OOP(Object Oriented Pragramming)와 스프링 프레임워크

1.OOP(Object Oriented Pragramming, 객체 지향 프로그래밍)를 하는 이유

  cf) 구들의 모든 서비스의 코드 라인 수는 ? 20억 줄...(2015년 기준)

  - 이렇게 많은 양을 어떻게 관리할까? (OOP를 잘 하는 방법)

    1) 분류 -  코드를 적절히 잘 분류해야한다.

    2) 교체 - 특정 모듈을 통째로 변경해야할 수도 있다.

 

  - 따라서, OOP는 소프트웨어를 말랑하게 유지하기 위한 것이라고 볼 수 있다.

 

 

2. OOP를 잘 하는 방법

  - OOP는 데이터(상태, field)와 로직(행위, methods)이 응집되서 상호 교류하면서 동작하도록 만드는 프로그래밍 기법을 말한다.

    -> OOP를 잘하는 방법 - 분류, 교체

 

• SOLID 원칙

• SRP(Singli Responsibility Principle, 단일 책임 원칙): 한 클래스는 단일의 책임만 가져야 한다. 충돌을 방지하고 역할에 해당하는 서비스를 잘 찾는다. (분류)
• OCP(Open Close Principle, 개방 폐쇄 원칙): 확장에는 열려있고 변경에는 닫혀있다.(클래스를 수정하지 말고 확장해야한다.)  if-else에서 반복적인 케이스가 보이면 클래스 분리를 고려한다. (교체)
• LSP(Liskov Substitution Principle, 리스코프 치환 법칙): 서브 타입은 언제나 기반 타입으로 교체할 수 있어야한다. (상속 받은 클래스는 부모 클래스의 동일한 동작을 해야 재활용 가능성 높아진다.) 상속 보다는 IF를 고려하고 상속을 해도 비슷하게 만들어야 교체가 쉽다. - 부모 타입을 인터페이스처럼 생각(교체)
• ISP(Interface Segregation Principle, 인터페이스 분리 원칙): 인터페이스도 (OCP를 따르도록) 단일 책임을 갖도록 분리해야한다. SRP와 유사하지만 인터페이스도 단일의 책임을 갖도록 설계해야 필요한 기능만 구현하고 제공 가능하다. (분류)
• DIP(Dependency Inversion Principle, 의존성 역전 원칙): 하위 모듈의 변경이 상위 모듈의 변경을 요구하는 의존성을 끊어내야한다. 중간 IF를 둬야 하위 모듈 변경이 쉽다.  (교체) ex) 내가 사용하던 라이브러리를 다른 라이브러리로 변경하면 내 코드를 뜯어고쳐야한다. 따라서, 라이브러리에 의존하면 교체 어렵다. 

      

  cf) 실무에서는 의외로 상속을 많이 사용하지 않는다. 기능을 너무 확장하거나 변경하면 재활용성이 낮아진다.

    - 상속을 위해 설계한 클래스만 상속한다.

    - 부모 클래스 상속 대신 인터페이스를 활용하라 (요즘 인텔리제이에는 인터페이스에서 public method만 추출해서 새로운 인터페이스 만드는 기능 있다.)

    - 반드시 상속을 해야하는 경우는 부모와 상호 치환이 가능하도록 한다.

 

• 강사님의 조언!

• KISS(Keep It Simple Stupid) => 기획 내용을 검토한 다음 그대로 만들기 보다는 예외가 있더라도 코드가 복잡하지 않도록 한다.
• YAGNI(You Ain't Gonna Need It) => 현재 쓰지 않는 코드는 과감하게 지운다. 쓸모없는 자원 낭비

 

3. SOLID 잘 하는 방법 - Spring

  1) 분류 - SRP, ISP

    - Spring이 표준적인 layer별 역할을 제공한다.

    - 클래스의 역할이 명확해지고 코드 파악이 쉬워진다.

 

 

  2) 교체 - OCP, LSP, DIP

 

  

  3) 스프링은 써야하는 이유?

    - SOLID를 지키려고 짜다보면 결국 스프링과 비슷한 기능을 만들게 된다.