Skip to content

Instantly share code, notes, and snippets.

@vandbt
Last active May 21, 2018 03:53
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save vandbt/2401d7385f10503735ba8e8233a1d8d3 to your computer and use it in GitHub Desktop.
Save vandbt/2401d7385f10503735ba8e8233a1d8d3 to your computer and use it in GitHub Desktop.
SOLID - design principles

SOLID Principles

cover SOLID

설계 원칙은 관리가능(maintainable)하고 재사용(reusable) 가능한 소프트웨어를 작성하기 위해 제시된 기준 입니다.

SOLID Principle은 Uncle Bob으로 알려진 Robert C. Martin 이 정리한 Object-Oriented Design (OOD) Principles.

  • Single responsibility principle: A class should have one, and only one, reason to change
  • Open-closed principle: You should be able to extend a classes behavior, without modifying it
  • Liskov substitution principle: Derived classes must be substitutable for their base classes
  • Interface segregation principle: Make fine-grained interfaces that are client specific
  • Dependency inversion principle: Depend on abstractions, not on concretions

Single responsibility principle

class는 오직 한 가지 이유에 의해 변경되어야 하며, 그러기 위해서 class는 하나의 책임만을 가져야 한다.

Open-closed principle

1998년 Bertrand Meyer가 제안한 원칙, class의 'behavior'는 수정 없이 확장(extend) 가능해야 한다.

프로그램은 모든 Entity들에 의존하고 있으므로, '이미 사용되고 있는' Entity의 수정은 전체 프로그램을 깨트릴 수 있음을 의미한다.

우리는 확장(extend)를 제외하고는 절대 변하지 않는 Entity를 가지는 것이 좋다.

이상적으로 어떤 Entity에 Test가 작성되고 통과 되었다면, 새로운 기능이 추가되는 상황을 제외하고 변경 없이 유지 되어야 한다.

Liskov substitution principle

Barbara Liskov가 제안한 원칙.

파생된(drived) 클래스는 그들의 베이스(base) 클래스와 치환(substitution) 될 수 있어야 한다.

Interface segregation principle

인터페이스는 비대해지려는 경향이 있으므로 충분히 잘게 분리하여 클라이언트가 필요한 것만 사용할 수 있게 해야 한다.

충분히는 크기에 따른 장단점이 있으므로 Trade-off를 의미합니다.  

It's about granularity

fine-granined 인터페이스를 최대한 작은 크기로 만듦

  • Pros : 필요한 것만 조합해서 사용할 수 있음.
  • Cons : 많은 Round-trip을 유발 할 수 있음.

coarse-grained 인터페이스를 굵은 크기로 만듦

  • Pros : Round-trip이 적음
  • Cons : Client에게 불필요 인터페이스가 포함됨 가능성이 높음, 유지보수성에 악영향

Dependency inversion principle

Entity는 구상(Concretion)이 아닌 추상(Abstraction)에 의존 해야 한다.

상위레벨(Hier level) 코드는 하위레벨(low-level)의 구현(implementation)에 직접 의존하는 대신 구현을 주도(leads)하는 추상(abstraction)에 의존 해야 한다.

추상은 구상보다 변화가 적고 견고하므로 추상에 의존할 수록 변경 요인이 적은 프로그램이 될 수 있다.

see also
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment