OOP/SOLID

객체지향 프로그래밍(OOP)

• Object Oriented Programing
• 데이터(Field)와 로직(Methods)이 응집되어 상호 교류하며 동작하도록 만드는 프로그래밍 기법

OOP가 필요한 이유

• 2015년 기준 구글의 코드는 20억 줄이다. 이러한 코드를 어떻게해야 쉽게 관리할까?
  1. 분류(코드를 적절히 잘 분류할 수 있어야 한다)
     • Class
       • 프로그램의 코드를 체계적으로 분류
       • 같은 역할을 하는 코드를 응집성 있게 모아줌
  2. 교체(경우에 따라 특정 모듈을 통째로 변경해야 할 수도 있다)
     • 변경이 어려운 이유들
       1. 너무 복잡하게 기능이 섞여 있어서 어디를 어떻게 고쳐야할지 파악이 어렵다
       2. 기능 추가 후에 기존에 잘 돌던 기능들이 갑자기 동작하지 않는다
       3. 내가 고친 곳과 상관 없는 전혀 엉뚱한 곳이 갑자기 잘못 동작한다

SOLID 원칙

• 단일 책임 원칙(SRP : Single Responsibility Principle)

  • 하나의 클래스는 하나의 책임만 가져야 한다.

• 개방 폐쇄 원칙(OCP : Open-Closed Principle)

  • 확장에는 열려있고, 변경에는 닫혀 있다.
    • 수정하지 말고, 클래스를 새로 추가

• 리스코프 치환 법칙(LSP : Liskov Substitution Principle)

  • 서브타입은 언제나 기반타입으로 교체할 수 있어야 한다.
    • 상속받은 클래스는 부모클래스와 동일한 동작을 해야 재활용 가능성이 높아진다.
  • 실무에선 의외로 상속을 많이 사용하지 않는다.
    • 상속 시 오버라이드를 한것과 아닌 것의 혼란
    • 상속 오버라이드를 잘못하면 로직 충돌(Fragile base class 문제)
    • 기능을 너무 확장하거나 변경하면 재활용성 낮아짐
  • 상속의 대안 또는 상속을 잘 하는 방법
    • 상속을 위한 설계를 한 클래스망 상속하라
    • 부모 클래스 상속 대신 인터페이스를 활용
    • 피할 수 없다면 상속을 하지만 부모와 상호 치환이 가능하도록 하라
      • 부모 클래스와 동일한 기능 제공
• 인터페이스 분리 원칙(ISP : Interface segregation principle)
  • Interface도 단일 책임을 갖도록 분리해야 한다
• 의존성 역전 원칙(DIP : Dependency Inversion Principle)
  • 하위 모듈의 변경이 상위 모듈의 변경을 요구하는 의존성을 끊어내야 한다.

SOLID를 잘하는 방법(스프링)

• 분류(SRP,ISP)
  • 스프링 MVC에서 가장 대중적으로 활용되는 역할 분리 방법
    1. 클래스의 역할이 조금 더 명확해짐
    2. 코드의 파악이 더 쉬워짐

• 교체(OCP, LSP, DIP)
  • DI Container(Depencdency Injection Container)
  • DI Config