SOLID

[Glsme]

🗓️ 마감일

2023.01.29

💁 참여자

• [x] 김도이
• [x] 윤여진
• [x] 홍석준
• [x] 이주영
• [x] 이재용

⚠️ 마지막으로 답변 단 사람이 이슈 close 하고 리드미에 항목 업데이트 해주세요.

[Yun-YeoJin]

프로그래머가 시간이 지나도 유지 보수와 확장이 쉬운 시스템을 만들고자 할 때 이 원칙들을 함께 적용할 수 있습니다. SOLID 원칙들은 소프트웨어 작업에서 프로그래머가 소스 코드가 읽기 쉽고 확장하기 쉽게 될 때까지 소프트웨어 소스 코드를 리펙토링 하여 코드 냄새(코드에서 더 심오한 문제를 일으킬 가능성이 있는 코드의 특징)를 제거하기 위해 적용할 수 있는 지침입니다!

즉, 객체 설계에 필요한 5가지 원칙으로써 유지보수가 쉽고, 유연하고, 확장이 쉬운 소프트웨어를 만들기 위한 수단

1. SRP (Single Responsibility) - 단일 책임 원칙

• 클래스는 단 한 개의 책임(기능)을 가져야 합니다.
• 클래스를 변경하는 이유는 단 하나여야 합니다.
• 이를 지키지 않으면, 한 책임의 변경에 의해 다른 책임과 관련된 코드에 영향을 미칠 수 있습니다. → 이렇게 되면 유지보수가 매우 비효율적이게 됩니다 ㅠ.ㅠ → (새로운 요구사항이나 프로그램 변경에 의해 클래스 내부의 동작들이 연쇄적으로 변경되어야 하면, 유지보수가 비효율적이게 되므로, 기능을 잘게 쪼개어 분리시킬 필요가 있습니다!)

2. OCP (Open-Closed) - 개방-폐쇄 원칙

• 확장에는 열려있어야 하고, 변경에는 닫혀 있어야 합니다.
• 즉, 기존의 코드를 변경하지 않고 기능을 수정하거나 추가할 수 있도록 설계해야 한다는 말입니다.
• 어떤 모듈의 기능을 하나 수정할 때, 그 모듈을 이용하는 다른 모듈들 역시 줄줄이 고쳐야 한다면 유지보수가 복잡할 것입니다.
• 따라서 개방 폐쇄 원칙을 잘 적용하여 기존 코드를 변경하지 않아도 기능을 새롭게 만들거나 변경할 수 있도록 해야 합니다.
• 그렇지 않으면 객체지향 프로그래밍의 가장 큰 장점인 유연성, 재사용성, 유지보수성 등을 모두 잃어버리는 셈

3. LSP (Liskov Substitution) - 리스코프 치환 원칙

• 하위 타입 객체는 상위 타입 객체에서 가능한 행위를 수행할 수 있어야 합니다. 즉, 상위 타입 객체를 하위 타입 객체로 치환해도 정상적으로 동작해야 한다는 말입니다!
• 상속관계에서는 꼭 일반화 관계가 성립해야 한다는 의미입니다.
• 상속관계가 아닌 클래스들을 상속관계로 설정하면, 이 원칙이 위배됩니다.
• ❌ 리스코프 치환 원칙을 지키지 않으면 개방 폐쇄 원칙을 위반하게 되는 것입니다. 기능 확장을 위해 기존의 코드를 여러 번 수정해야 할 것이다.
• 따라서 상속 관계를 잘 정의하여 LSP 원칙이 위배되지 않도록 설계해야 합니다!

4. ISP (Interface Segregation) - 인터페이스 분리 원칙

• 클라이언트는 자신이 사용하는 메서드에만 의존해야 한다는 원칙입니다.
• 한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 않아야 합니다.
• 인터페이스는 해당 인터페이스를 사용하는 클라이언트를 기준으로 잘게 분리되어야 합니다.
• 🟢 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
• 클라이언트가 사용하지 않는 인터페이스에 변경이 발생하더라도 영향을 받지 않도록 만들어야 하는 것이 핵심입니다.

5. DIP (Dependency Inversion) - 의존 역전 원칙

• 의존 관계를 맺을 때, 변하기 쉬운 것(구체적)보다는 변하기 어려운 것(추상적)에 의존해야 합니다.→ 구체화된 클래스에 의존하기보다는 추상적인 클래스나 인터페이스에 의존해야 한다는 뜻!
• 저수준 모듈이 고수준 모듈에서 정의한 추상 타입에 의존해야 합니다.
• 저수준 모듈이 변경되어도 고수준 모듈은 변경이 필요 없는 형태가 이상적인 형태입니다.

[Glsme]

SOLID 원칙

객체 지향 프로그래밍 시 지켜야 할 SRP, OCP, LSP, ISP, DIP 원칙을 정리한 용어이다.

S: Single Responsibility Principle

• 단일 책임 원칙
• 클래스나 함수를 설계할 때 각 단위들은 단 하나의 책임만을 가져야 한다.
  
  

  O: Open - Close Principle

• 개방 폐쇄 원칙
• 확장에는 열려있으나, 변경에는 닫혀있어야 한다.
  
  

  L: Liskov Substitution Principle

• 리스코프 치환 원칙
• 자식 객체가 부모 객체의 동작을 제한해선 안된다.
• 실제로 LSP를 절대적으로 지키면서 코드를 작성하기엔 어렵다.
  
  

  I: Interface Segregation Principle

• 인터페이스 분리 원칙
• 사용하지 않는 인터페이스는 구현하면 안된다.
  
  

  D: Dependency Inversion Principle

• 의존성 역전 원칙
• 상위 모듈은 하위 모듈에 의존해선 안된다.

[LeeJoobang]

SOLID

SOLID란? 객체 지향 프로그램 및 설계의 다섯가지 기본 원칙

1. S(SRP - 단일 책임 원칙)

• 모든 클래스는 하나의 책임만 가지며, 클래스는 그 책임을 완전히 캡슐화한다.

2. O(OCP - 개방 폐쇄 원칙)

• 소프트웨어 개체(클래스, 모듈, 함수 등)는 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다.
• 객체가 변경될 때 해당 객체만 바꿔도 동작이 잘되면 OCP를 자 지킨 것이라 할 수 있음.

3. L(LSP - 리스코프 치환 원칙)

• 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
• 서브 타입은 상속받은 기본타입으로 대체 가능해야 한다.
• 자식 클래스는 부모 클래스의 동작을 바꾸지 않는다.

4. I(ISP - 인터페이스 분리 원칙)

• 클라이언트가 자신이 이용하지 않는 메서드에 의존하지 않아야 한다는 원칙
• 클래스 내에서 사용하지 않는 인터페이스는 구현하지 말아야 한다.

5. D(DIP - 의존관계 역전 원칙)

• 상위 계층이 하위 계층에 의존하는 전통적인 의존관계를 반전시킴으로써 상위 계층이 하위 계층의 구현으로부터 독립되게 할 수 있다.
• 상위 모듈은 하위 모듈에 의존해서는 안된다.

[heydoy]

SOLID 원칙

SOLID는 객체지향의 5가지 원칙을 의미

1. Single Responsibility Principle 단일책임 원칙
2. Open/Closed Principle 개방/폐쇄 원칙
3. Liskov Substitution Principle 리스코프 치환 원칙
4. Interface Segregation 인터페이스 분리
5. Dependency Inversion 의존성 역전

Single Responsibility Principle

모든 모듈은 단 하나의 책임을 가져야 한다는 것.

Open/Closed principle

extension에는 개방, 수정에는 폐쇄

Liskov Substitution Principle

베이스 클래스에 포인터나 참조를 사용하는 함수는 반드시 파생된 클래스의 객체를 (알지못하더라도) 사용할 수 있어야한다.

Interface Segregation Principle (ISP)

클라이언트는 사용하지 않는 인터페이스를 구현하지 않아야하는 것. 하나의 큰 인터페이스보다, 각각 하나의 작은 서브모듈을 제공하는 메서드 그룹의 작은 인터페이스가 많은 것이 더 선호됨.

Dependency Inversion Principle

상위레벨 모듈은 하위레벨 모듈에 의존해서는 안되며, 둘 다 추상화에 의존해야한다. 추상화는 세부사항에 의존하는 것이 아니라, 세부사항이 추상화에 의존해야 한다.

• 참고: https://medium.com/@nishant.kumbhare4/solid-principles-in-swift-73b505d3c63f

[wodyddml2]

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

- 클래스나 함수를 설계할 때, 각 단위들은 단 하나의 책임 만을 가져야 하는 원칙
- 하나의 클래스에 하나의 책임 만을 가져야한다.
    - ex) APIService, Repository

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

- 기존의 코드는 변경하지 않으면서(Closed), 기능을 추가할 수 있도록(Open) 설계
- 기존의 코드를 변경해야하지 않기 때문에 기능 추가만 할 수 있도록 추상화 작업이 중요하다.

LSP(Liskov Substitution Principle) - 리스코프 치환 원칙

- 부모 클래스 인스턴스로 돌아가는 곳에, 자식 클래스 인스턴스를 넣었을 때 동일한 결과 값을 나타내야 한다.

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

- 사용하지 않는 인터페이스는 구현하지 말아야한다.
    - ex) 프로토콜 사용 시

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

- 상위 모듈은 하위 모듈에 의존해서는 안되며, 두 모듈 모두 추상화에 의존하게 만들어야 한다.
    - 보통 프로토콜(추상화)를 만들어 의존하게 한다. 
    - 즉, 중간 다리 역할, 유지보수 개이득