객체 지향의 SOLID 원칙

원: Bob Martin SOLID Principles of Object Oriented and Agile Design(https://www.youtube.com/watch?v=TMuno5RZNeE)

/* 영상에선 리스코프 치환 이야기하다 강의 종료 */

 

• 우리는 나쁜 코드가 프로그램을 느리게 만든다는 것을 알고 있다.
  • 그렇다면 우리는 왜 프로그램을 느리게 만드는 나쁜 코드를 작성하는가?
  • 시간에 쫒겨서 나쁜 코드를 작성하게 된다.
• 그렇다면 나쁜 코드란 무엇인가.
  • 나쁜 코드 -> 설명해줘야 함
    • 이게 무슨 코드지? 이걸 수정하면 어떤 일이 일어나는 거지? -> 나쁜 코드
  • 좋은 코드 -> 읽어보면 앎
    • 음, 그렇군. 이렇게 동작하는 건가? -> 좋은 코드
• 경직성
  • 코드를 수정할 때, 일관성을 유지하기 위해 다른 코드를 대량으로 수정해야 할 때 발생
  • 버그가 있을 때, 이 버그가 어디서 발생하는지 정확하게 인지하고 있음. 하지만 고치는 데 많은 시간이 소요될 수 있다.
    
    • 예를 들어, A 모듈에 있을 때, A 모듈의 함수를 호출하는 B 모듈을 수정하고, B 모듈의 함수를 호출하는 C 모듈을 수정하고, ...
  • 다른 모듈의 코드를 변경하지 않고는 독립적으로 변경할 수 없는 종속성이 강한 코드
• 취약성
  • 코드가 여러 곳에서 끊어지는 경향
  • A 모듈의 코드를 수정했을 때, B 모듈의 코드가 동작하지 않는 경우
• OO란
  • 아키텍쳐에서 특정 주요 종속성을 선택적으로 반전하여 종속성을 관리하는 방식으로 경직성, 취약성, 재사용 불가능성을 방지하는 것
• SOLID 원칙
  • 클래스 디자인 원칙
  • S: The Single Responsibility Principle
  • O: The Open Closed Principle
  • L: The Liskov Substitution Principle
  • I: The Interface Segregation Principle
  • D: The Dependency Inversion Principle
• SRP, The Single Responsibility Principle, 단일 책임 원칙
  • 하나의 클래스는 하나의 책임을 가지며, 무언가를 변경하는 하나의 책임만을 가져야 한다.
    • 책임: 단순히 함수를 의미하지 않고, 무언가를 변경하는 것에 대한 이유
• OCP, The Open Closed Principle, 개방 폐쇄 원칙
  • 클래스나 모듈은 확장에는 열려있어야 하지만, 수정에는 닫혀있어야 한다.
  • 클래스나 모듈을 변경하지 않아도 클래스나 모듈이 수행하는 작업을 변경할 수 있어야 하며, 클래스나 모듈의 동작을 변경할 수 있어야 한다.
  • 확장이 가능해야 하므로 동작은 확장 가능하지만, 수정은 불가능해야 한다.
  • 애플리케이션을 확장할 때, OCP를 준수한다면 기존 클래스나 모듈을 변경하지 않아도, 새로운 기능으로 애플리케이션을 확장할 수 있다.
  • 만약, 모듈안에 도형을 그리는 함수가 있을 때, OCP를 준수하지 않는다면 스위치 문으로 분기를 통해 이 도형이 사각형인지, 원인지, 삼각형인지 구분하고 있을 수 있다.
    • 이 때, 새로운 도형이 추가된다면 이 스위치 문에 새로운 도형 케이스를 추가해야 할 것이다.
    • 만약, 도형을 사용하는 모듈이 하나가 아니라면?
    • 스위치 문이 1개가 아닌 10개, 100개라면?
    • 취약성으로 인해 내가 미처 발견하지 못한 모듈에서 버그가 발생할 수 있다.
  • 상위 수준 존재가 하위 수준 존재의 세부 사항을 알지 못한다.
• LSP, The Liskov Substitution Principle, 리스코프 치환 원칙
  • 파생 클래스는 기본 클래스 인터페이스를 통해 사용할 수 있어야 한다.
  • 잘못된 상속 관계를 피하기
  • 상속 대신 구성을 선택하기
  • isa(is-a)가 아닌 hasa(has-a) 관계로 설계
  • 공통된 동작을 인터페이스로 추상화