본문 바로가기
Dev Log/Computer Science

객체 지향 설계 원칙 SOLID

by 삽질하는큐 2019. 4. 30.

로버트 마틴이 정리한 객체 지향 설계 원칙

 

  • SRP(The Single Responsibility Principle): 단일 책임 원칙
    • 모든 클래스는 하나의 책임만을 가지며 클래스는 그 책임을 완전히 캡슐화 해야 한다. 어떤 클래스나 모듈은 변경하려는 단 하나의 이유만을 가져야 한다.
    • 도메인 객체와 웹 객체를 함께 쓰거나, 영속성 객체와 함께 쓰게되면 애플리케이션이 단순할 때는 상관이 없지만, 다른 객체의 변화에 따라 도메인 객체가 함께 변화될 수 있다.
  • OCP(The Open Closed Principle): 개방 폐쇄 원칙
    • 객체는 확장에는 열려 있어야 하고 변경에는 닫혀 있어야 한다.
    • '확장'은 기능 확장을 말하는 것. 의존성 주입을 통해서 기능을 확장. 
    • '변경'은 기존 로직의 변경을 말함. 불변객체를 생각하면 될 듯하다.
    • TDD(켄트백)에서는 "사용에는 열려 있고 수정에 닫혀 있어야 한다"고 말한다.
  • LSP(The Liskov Substitution Principle): 리스코프 치환 원칙
  • ISP(The Interface Segregation Princlple): 인터페이스 분리 원칙
    • 클라이언트가 오로지 자신이 필요로 하는 메서드만 알면 되도록 넓은 인터페이스를 특화된 인터페이스로 분리해야 한다.
    • UserService의 Use Case가 여러개가 있다면 RegisterUserService, LoginService, EmailValidationService 등으로 분리한다.
  • DIP(The Dependency Inversion Principle): 의존관계 역전 원칙
    • 모듈은 다른 모듈의 추상화에 의존해야 한다.
    • 높은 수준의 모듈이 낮은 수준의 모듈에 의존했던 전통적인 방식과는 달리 추상화를 통해서 의존성의 방향을 역전시킨다.
    • Dependency Injection과 DIP는 엄연히 다른 개념이며, DIP를 달성하는 방법으로 DI를 사용할 수 있다.

모든 클래스는 하나의 책임만 가지며, 클래스는 그 책임을 완전히

모든 클래스는 하나의 책임만 가지며, 클래스는 그 책임을 완전히

모든 클래스는 하나의 책임만 가지며, 클래스는 그 책임을 완전히

모든 클래스는 하나의 책임만 가지며, 클래스는 그 책임을 완전히 캡슐화해야 함

모든 클래스는 하나의 책임만 가지며, 클래스는 그 책임을 완전히 캡슐화해야 함모든 클래스는 하나의 책임만 가지며, 클래스는 그 책임을 완전히 캡슐화해야 함모든 클래스는 하나의 책임만 가지며, 클래스는 그 책임을 완전히 캡슐화해야 함

 

'Dev Log > Computer Science' 카테고리의 다른 글

MSA, Microservice Architecture 장단점  (0) 2019.04.30
화이트박스 vs 블랙박스  (0) 2019.04.17