[Design Pattern] Solid Principles (솔리드 원칙)

Solid Principles (솔리드 원칙)

SOLID 원칙은 객체 지향 프로그래밍과 소프트웨어 엔지니어링에서 좋은 코드 설계를 위한 다섯 가지 기본적인 원칙을 말합니다.
이 원칙들은 코드의 유지보수성을 향상시키고, 확장성을 용이하게 하며, 복잡성을 관리하는 데 도움을 줍니다. 5개의 원칙이 있습니다.

 

• S - Single Responsibility Principle (단일 책임 원칙)
  • 각 클래스는 하나의 책임만을 가져야 합니다. 즉, 시스템에서 변경이 필요한 한 가지 이유만을 가지고 있어야 합니다. 이 원칙은 코드의 재사용성을 높이고, 변경에 대한 유연성을 증가시킵니다.
• O - Open/Closed Principle (개방/폐쇄 원칙)
  • 소프트웨어의 엔티티(클래스, 모듈, 함수 등)는 확장에 대해서는 열려 있어야 하지만, 변경에 대해서는 닫혀 있어야 합니다. 즉, 기존의 코드를 변경하지 않고도, 시스템의 기능을 확장할 수 있어야 합니다. 이 원칙은 유연하고 확장성 있는 소프트웨어 설계를 가능하게 합니다.

• L - Liskov Substitution Principle (리스코프 치환 원칙)
  • 프로그램에서 부모 클래스의 인스턴스를 자식 클래스의 인스턴스로 대체할 수 있어야 합니다(단, 부모 클래스의 인스턴스를 사용하는 곳에 자식 클래스의 인스턴스를 두어도 프로그램의 의미가 변경되지 않아야 합니다). 이 원칙은 상속을 사용할 때의 가이드라인을 제공합니다.
• I - Interface Segregation Principle (인터페이스 분리 원칙)
  • 클라이언트는 자신이 사용하지 않는 메소드에 의존하게 되어서는 안 됩니다. 이 원칙은 '큰' 인터페이스를 클라이언트가 실제로 사용하는 메소드만 포함하는 여러 개의 '작은' 인터페이스로 분리해야 한다고 주장합니다. 이는 인터페이스의 분리를 통해 시스템의 결합도를 낮추고, 유연성을 향상시킵니다.
• D - Dependency Inversion Principle (의존성 역전 원칙)
  • 고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 둘 다 추상화에 의존해야 합니다. 추상화는 세부 사항에 의존해서는 안 되며, 세부 사항은 추상화에 의존해야 합니다. 이 원칙은 모듈 간의 의존성을 관리하는 방법을 제시하여, 코드의 재사용성과 유지보수성을 높입니다.

---

Single Responsbility Principle (SRP-단일 책임 원칙)

• 단일 책임 원칙(SRP, Single Responsibility Principle)은 소프트웨어 설계의 SOLID 원칙 중 하나로, 모든 클래스는 단 하나의 책임만을 가져야 한다는 원칙입니다.
• 이 원칙의 핵심은 '책임'을 어떻게 정의하느냐에 있으며, 여기서 책임은 변경이 필요할 때 그 변경을 이유로 하는 기능이나 이유를 의미합니다.
• 클래스를 구현할 때 한가지 기능에만 중점을 두어야 합니다. 두가지 이상의 기능이 필요하면 클래스를 나눠야 합니다.
• 즉, 한 클래스는 한 가지의 변경 이유만을 가져야 합니다.
• 단일 책임 원칙을 따르는 클래스 설계는 다음과 같은 이점을 제공합니다.
• 특정 기능을 수정할 때 관련 클래스 외에는 건드릴 필요가 없고, 한개의 클래스에 여러가지 기능이 있다면 관련된 모든 클래스를 수정해야하는 상황이 발생할 수 있습니다.

 

1. 유지보수성 향상: 특정 기능에 대한 수정이 필요할 때, 그 변경이 필요한 클래스만을 수정하면 되므로, 시스템의 다른 부분에 대한 영향을 최소화할 수 있습니다. 이는 유지보수의 복잡성과 관련된 비용을 줄여줍니다.
2. 이해하기 쉬운 코드: 클래스가 단 하나의 책임을 가지고 있으면, 그 클래스의 역할과 기능이 명확해집니다. 이로 인해 코드의 가독성이 향상되며, 다른 개발자들이 코드를 이해하고 수정하는 데 소요되는 시간이 단축됩니다.
3. 재사용성 증가: 단일 책임을 가진 클래스는 그 기능이 다른 시스템이나 애플리케이션에서도 필요할 때 재사용하기가 더 쉽습니다. 이는 코드의 중복을 줄이고, 개발 시간을 단축시킬 수 있습니다.
4. 테스트 용이성: 한 클래스가 하나의 책임만을 가질 경우, 그 기능에 대한 테스트가 더 쉬워집니다. 복잡한 의존성이 줄어들기 때문에, 특정 기능에 대한 단위 테스트를 작성하고 실행하는 것이 간단해집니다.

 

• 단일 책임 원칙을 적용할 때 주의할 점은, '책임'의 범위와 정의를 너무 좁게 보지 않도록 해야 합니다.
• 너무 많은 세분화는 오히려 관리해야 할 클래스의 수가 증가하여 복잡성을 높일 수 있습니다.
• 따라서, 적절한 수준에서 클래스의 책임을 분리하는 균형을 찾는 것이 중요합니다.
  
  

---

Example

• Add 함수는 덧셈을 하는것에만 책임을 다해야 합니다.
• numPrint 함수는 숫자를 출력하는 것에만 책임을 다 해야합니다.
• addPrint함수는 Single Responsbility 원칙을 따르지 않습니다.

클래스로 작성된 코드의 예시

---

Open-Close Principle (OCP, 개방-패쇄원칙)

개방-폐쇄 원칙(OCP, Open-Closed Principle)은 소프트웨어 설계의 중요한 원칙 중 하나로, 유연하고 확장 가능하며, 동시에 안정적인 소프트웨어 시스템을 구축하고자 할 때 매우 중요합니다.

 

• 개방-폐쇄 원칙(OCP, Open-Closed Principle)의 핵심 아이디어는 소프트웨어 컴포넌트(클래스, 모듈, 함수 등)가 새로운 기능이나 요구사항의 추가에는 열려 있어야 하지만, 기존의 소스 코드는 변경하지 않아야 한다는 것입니다.

개방-폐쇄 원칙의 목적

• 유지보수성 향상: 기존 코드를 변경하지 않고도 시스템을 확장할 수 있기 때문에, 시스템의 유지보수성이 크게 향상됩니다.
• 유연성 증가: 새로운 기능이나 요구사항을 쉽게 추가할 수 있어, 시스템의 유연성이 증가합니다.
• 재사용성 및 호환성: 기존의 검증된 컴포넌트를 재사용하면서도 새로운 기능을 추가할 수 있어, 코드의 재사용성과 호환성이 높아집니다.

개방-폐쇄 원칙을 적용하는 방법

• 추상화와 다형성 사용
  • 인터페이스나 추상 클래스를 사용하여 구체적인 구현을 숨기고, 다형성을 통해 확장 가능한 부분을 정의합니다.
  • 새로운 기능을 추가할 때 기존 코드를 수정하지 않고도 새로운 클래스를 추가하여 기능을 확장할 수 있습니다.
• 전략 패턴(Strategy Pattern) 활용
  • 특정 기능을 인터페이스로 정의하고, 그 인터페이스를 구현하는 여러 전략(구현체) 클래스를 제공함으로써, 실행 시간에 구현체를 변경할 수 있습니다. 이는 기능의 확장을 용이하게 합니다.
    
    
• 데코레이터 패턴(Decorator Pattern) 사용
  • 기존 객체의 기능을 동적으로 확장할 수 있는 구조를 제공합니다.
  • 이 패턴을 사용하면, 기존 코드를 수정하지 않고도 객체의 책임을 추가할 수 있습니다.
    
    
• 팩토리 메소드 패턴(Factory Method Pattern) 및 추상 팩토리 패턴(Abstract Factory Pattern) 적용
  • 객체 생성 로직을 클라이언트로부터 분리하여, 시스템에 새로운 클래스를 추가하더라도 기존 코드를 변경할 필요 없이 객체 생성이 가능하게 합니다.
    
    

---

Dependency Inversion Principle (의존관계 역전 원칙)

고수준 모듈(상위 계층)이 저수준 모듈(하위 계층)의 구현에 직접 의존하는 것이 아니라, 둘 다 추상화에 의존해야 한다는 원칙입니다.

• 의존관계 역전 원칙은 소프트웨어 모듈들을 분리하는 특정 형식을 지칭합니다.
• 상위 계층이 하위 계층에 의존하는 전통적인 의존관계를 반전(역전)시킴으로써 상위 계층이 하위 계층의 구현으로 부터 독립되게 할 수 있습니다.

의존관계 역전 원칙의 2가지 주요 사항

1. 고수준 모듈은 저수준 모듈에 의존해서는 안 된다
   • 두 모듈 모두 추상화에 의존해야 합니다. 고수준 모듈은 정책을 결정하고, 저수준 모듈은 이러한 정책의 구체적인 구현을 제공합니다.
   • 고수준 모듈이 저수준 모듈의 구현에 의존하면, 저수준 모듈의 변경이 고수준 모듈에 영향을 미치게 됩니다.
2. 추상화는 세부 사항에 의존해서는 안 된다
   • 세부 사항이 추상화에 의존해야 합니다. 이는 고수준의 정책을 설정하는 추상화가, 저수준의 구현 세부 사항에 영향을 받지 않아야 함을 의미합니다.
   • 추상화는 변경에 강해야 하며, 구체적인 구현 세부 사항에 의해 영향을 받지 않아야 합니다.
     
     

의존관계 역전 원칙의 이점

• 유연성과 확장성 향상: 구현 세부 사항이 아닌 추상화에 의존함으로써, 새로운 기능이나 요구사항의 추가가 용이해집니다.
• 유지보수성 증가: 하위 모듈의 변경이 상위 모듈에 영향을 미치지 않아, 시스템의 유지보수가 용이해집니다.
• 재사용성 개선: 추상화를 통해 공통의 인터페이스를 제공함으로써, 다양한 상황에서 재사용성이 개선됩니다.
  
  

Example

여기서 클래스는 Cat, Dog 클래스들에 의존 관계가 있습니다.. 동물들이 늘어나면 Zoo클래스를 계속 수정해야헙나더,

 

의존관계가 Animal 추상 클래스에 의해 역전되었고, Zoo 클래스는 각 Cat, Dog 등의 클래스로부터 독립되었습니다.

 

왼쪽: DIP 따르지 않음, 오른쪽: DIP 따름

---

Liskov Substitution Principle

이 원칙은 하위 타입의 객체가 상위 타입의 객체와 동일하게 행동해야 한다는 개념을 기반으로 합니다.

• 컴퓨터 프로그램에서 자료형 S가 자료형 T의 하위형이라면 필요한 프로그램의 속성(정확성, 수행하는 업무 등)의 변경 없이 자료형 T의 객체를 자료형 S의 객체로 교체(치환)할 수 있어야 한다는 원칙입니다.

리스코프 치환 원칙의 핵심

• 호환성: 하위 클래스는 상위 클래스의 행동 규약과 호환되어야 합니다.
  • 즉, 상위 클래스의 인스턴스를 하위 클래스의 인스턴스로 대체해도, 프로그램의 기능이 변하지 않아야 합니다.
• 치환성: 상위 클래스의 인스턴스를 하위 클래스의 인스턴스로 치환(교체)할 때, 프로그램의 정확성이 유지되어야 합니다

리스코프 치환 원칙의 중요성

• 유연성과 재사용성 향상: 하위 클래스가 상위 클래스와 완벽하게 호환되면, 코드의 재사용성과 시스템의 유연성이 증가합니다.
• 유지보수성 증가: LSP를 준수하는 설계는 시스템의 유지보수를 용이하게 합니다.
  • 상위 클래스의 변경이 하위 클래스에 불필요한 영향을 주지 않으며, 하위 클래스를 수정하여도 상위 클래스와의 호환성이 유지됩니다.
• 확장성 개선: 새로운 하위 클래스를 추가하거나 기존 하위 클래스를 수정할 때, 전체 시스템의 안정성과 호환성을 유지하면서 확장이 가능합니다.

적용 방법

• 인터페이스 분리: 상위 클래스의 인터페이스를 세분화하여, 하위 클래스가 필요로 하는 기능만을 상속받도록 합니다.
• 계약에 의한 설계: 메소드가 요구하는 사전 조건(preconditions)과 사후 조건(postconditions)을 명확히 정의하여, 이 계약을 모든 하위 클래스가 준수하도록 합니다.

---

Example

---

Interface Segregation (인터페이스 분리 원칙)

클라이언트가 자신이 사용하지 않는 메소드에 의존하지 않아야 한다는 개념을 기반으로 합니다

• 큰 덩어리의 Interface 를 구체적이고 작은 단위로 분리시킴 으로써 Client들이 꼭 필요한 Method들만 이용할 수 있도록 해야합니다.

인터페이스 분리 원칙의 핵심 포인트

• 클라이언트 특화 인터페이스: 클라이언트는 자신이 실제로 사용하는 메소드만을 포함하는 인터페이스에 의존해야 합니다.
  • 이를 통해 불필요한 의존성을 제거하여 시스템의 결합도를 낮춥니다.
• 작은 인터페이스로 분리: 크고 일반적인 인터페이스는 보다 구체적이고 작은 여러 인터페이스로 분리되어야 합니다.
  • 이 작은 인터페이스들은 특정 클라이언트 그룹의 요구사항을 더 정확하게 반영할 수 있습니다.

인터페이스 분리 원칙의 이점

• 유연성 향상: 클라이언트에 맞춤화된 인터페이스를 제공함으로써, 시스템의 다른 부분을 변경하지 않고도 새로운 기능이나 요구사항을 쉽게 통합할 수 있습니다.
• 유지보수성 증가: 클라이언트가 자신이 사용하지 않는 메소드에 의존하지 않기 때문에, 한 인터페이스의 변경이 다른 클라이언트에 미치는 영향이 줄어들어 유지보수가 용이해집니다.
• 재사용성 개선: 더 작고 구체적인 인터페이스는 재사용 가능성이 높아집니다. 클라이언트는 필요한 기능만을 포함하는 인터페이스를 선택하여 사용할 수 있으므로, 코드의 재사용성이 증가합니다

---

Example