Software Development/SW Architecture

SOLID Principle & Component Design Principles

huiyu 2024. 7. 21. 19:48

1. SOLID Principle

  • SRP(Single Responsibility Principle, 단일 책임원칙)
    • 한 클래스는 하나의 책임만 가져야 한다.
    • 목적 : 시스템의 복잡성을 낮추고, 한 클래스가 하나의 기능만을 가져 수정을 용이하게 하여 유지보수를 용이하게 한다. 한 클래스가 여러 기능을 맡으면 하나의 기능에 문제가 생겼을 때 다른 기능에도 영향을 줄 수 있다.
  • OCP(Open/Closed Principle, 개방-폐쇄 원칙)
    • 확장에는 열려있고 변경에는 닫혀있어야 한다.
    • 목적 : 기존의 코드를 수정없이 시스템의 기능을 확장할 수 있게 한다. 이는 기존 코드의 오류 가능성을 줄이면서 새로운 기능을 쉽게 추가할 수 있다.
  • LSP(Liskov Substitution Principle, 리스코프 치환 원칙)
    • 서브 클래스는 기반 클래스로 교체할 수 있어야 한다. 서브 클래스는 기반 클래스의 동작을 수정하지 않고 확장만 가능해야 한다.
    • 목적 : 상속을 통해 클래스를 확장할 때, 기반 클래스의 기능을 수정하지 않고 확장할 수 있어야 한다. 새로운 서브 클래스를 사용해도 기존 시스템은 올바르게 동작해야 한다.
  • ISP(Interface Segregation Principle, 인터페이스 분리 원칙)
    • 하나의 인터페이스를 여러 클래스가 공유하지 않도록 인터페이스는 기능에 맞게 분리해서 나누어야 한다.
    • 목적 : 사용하지 않는 메소드에 대한 불필요한 의존성을 제거하며, 더 관리가 용이한 코드를 설계할 수 있다.
  • DIP(Dependency Inversion Principle, 의존성 역전 원칙)
    • 구체적인 구현 클래스에 의존하기 보다는 상위 인터페이스에 의존해야 한다.
    • 목적 : 시스템의 결합도를 줄이고, 인터페이스에 의존하여 구현함으로써, 코드 수정 시 변경을 줄이고 시스템의 유연성을 높일 수 있다.

 

2. Component Design Principles

  • Cohesion
    • REP (Reuse/Release Equivalence Principle)
      • 재사용 가능한 컴포넌트는 함께 릴리스되고, 동일한 버전 관리와 릴리스 문서화를 공유해야 하는 원칙
    • CCP (Common Closure Principle) - 공통 폐쇄 원칙
      • 동일한 이유로 변경되는 클래스들은 하나의 컴포넌트로 묶여야 하며, 다른 이유로 변경되는 클래스들은 분리해야 하는 원칙
    • CRP (Common Reuse Principle) - 공통 재사용 원칙
      • 함께 재사용되는 클래스들은 하나의 컴포넌트로 묶여야 하며, 사용하지 않는 클래스가 포함된 컴포넌트에 의존하지 않아야 하는 원칙
    • Coupling
      • ADP(Acyclic Dependencies Principle)
        • 의존성 그래프에 순환(cyclic)이 없도록 설계하여, 변경이 순환 의존성을 통해 전파되는 것을 방지하는 원칙.
      • SDP(Stable Dependency Principle)
        • 안정적인 컴포넌트는 불안정한 컴포넌트에 의존하지 않아야 하며, 안정성은 의존성의 방향에 따라 전파되는 원칙.
      • SAP(Stable Abstractions Principle)
        • 안정적인 컴포넌트는 추상화 수준이 높아야 하며, 불안정한 컴포넌트는 구체적인 구현을 포함해야 하는 원칙.
  • Component Interface Design Principles
    • Separate Interface : 인터페이스 분리
    • ISP(Interface Segregation Principle) : 인터페이스 분리 원칙
    • Use Abstract Name : 추상적인 이름 사용
    • Use outcome-revealing name : 결과를 드러내는 이름 사용
    • Use implementation-free name : 구현에 종속되지 않은 이름 사용
    • Make Interface Abstract : 인터페이스를 추상적으로 만들기
    • Data Abstraction(데이터 추상화) : 파라미터 객체 도입, 전체 객체 보존, 추상 데이터 타입 도입
    • Functional Abstraction(기능 추상화) : 퍼사드 함수 도입
    • Implementation abstraction(구현 추상화) : 컬렉션 캡슐화, 파라미터를 메소드로 대체, 파라미터를 명시적 메소드로 대체, 메소드 매개변수화
    • Minimize Dependency : 의존성 최소화
    • DIP(Dependency Inversion Principle) : 의존성 역전 원칙
    • Law of Demeter : 디메테르 법칙, 위임 숨기기
728x90

'Software Development > SW Architecture' 카테고리의 다른 글

Factory Method Pattern  (0) 2024.07.08
Command Pattern  (0) 2024.07.08
Tactics and Patterns for Software Robustness  (0) 2024.06.28
CQRS Pattern에 대한 자세한 설명  (0) 2024.06.28
Event Driven Architecture (EDA)  (0) 2024.06.28