맨위로가기

SOLID (객체 지향 설계)

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

SOLID는 객체 지향 프로그래밍 설계의 다섯 가지 기본 원칙을 나타내는 약어이다. 이 원칙들은 소프트웨어 설계의 유연성, 유지 보수성, 확장성을 높이기 위해 고안되었다. SOLID는 단일 책임 원칙(SRP), 개방-폐쇄 원칙(OCP), 리스코프 치환 원칙(LSP), 인터페이스 분리 원칙(ISP), 의존관계 역전 원칙(DIP)으로 구성된다. 각 원칙은 클래스 및 모듈의 설계에 대한 구체적인 지침을 제공하며, 로버트 C. 마틴에 의해 소개되었고, 2004년경 마이클 페더스에 의해 SOLID라는 약어로 정리되었다.

더 읽어볼만한 페이지

  • 프로그래밍 원칙 - 블랙박스
    블랙 박스는 자극 입력과 출력 반응의 관점에서 시스템을 추상화하여 외부적으로 관찰하는 이론으로, 전자 회로 이론, 사이버네틱스, 시스템 이론 등 다양한 분야에서 활용되며 예측 모델 구축 및 유효성 검증, 그리고 항공기 비행 기록 장치나 함수 교육 도구 등 실생활에도 응용된다.
  • 프로그래밍 원칙 - 정보 은닉
    정보 은닉은 소프트웨어 설계에서 모듈 내부 구현을 숨기고 정의된 인터페이스를 통해서만 상호 작용하도록 하여 모듈 독립성을 높이고 시스템 복잡성을 관리하는 데 중요한 기법으로, 객체 지향 프로그래밍의 캡슐화와 관련된다.
  • 소프트웨어 설계 - 구조적 분석
    구조적 분석은 1960년대에서 1980년대 소프트웨어 개발의 복잡성을 해결하기 위해 개발된 기법으로, 다이어그램과 데이터 사전을 활용하여 시스템을 분석하고 설계했으며, 객체 지향 프로그래밍의 등장으로 활용도가 감소했다.
  • 소프트웨어 설계 - 지속적 배포
    지속적 배포(CD)는 소프트웨어 릴리스 프로세스를 자동화하는 접근 방식이며, 배포 파이프라인을 통해 구현되고 시장 출시 시간 단축, 제품 품질 향상 등의 이점을 제공하지만 테스트 자동화 부족 등의 과제도 존재한다.
  • 객체 지향 프로그래밍 - Is-a
    Is-a 관계는 객체 지향 프로그래밍에서 한 유형이 다른 유형의 하위 유형임을 나타내는 관계로, 상속, 서브타이핑, 리스코프 치환 원칙과 관련되며, C++, Python, Java 등에서 표현된다.
  • 객체 지향 프로그래밍 - 객체 (컴퓨터 과학)
    객체는 객체 지향 프로그래밍에서 데이터와 조작을 묶어 메시지를 수신하고, 프로그램의 개념을 표현하며 가시성과 재사용성을 높이는 실체이다.
SOLID (객체 지향 설계)
SOLID 원칙 개요
설명SOLID 원칙은 객체 지향 프로그래밍 및 설계에서 따르는 5가지 설계 원칙을 지칭한다. 이 원칙들을 함께 적용하면 개발자가 유지 보수 및 확장이 용이한 시스템을 구축하는 데 도움이 된다. SOLID 원칙은 소프트웨어 개발자가 코드를 더 이해하기 쉽고, 변경하기 쉽고, 테스트하기 쉽게 만드는 방법이다. SOLID는 로버트 C. 마틴이 2000년대 초반에 소개한 약어이다.
원칙 목록단일 책임 원칙
개방-폐쇄 원칙
리스코프 치환 원칙
인터페이스 분리 원칙
의존관계 역전 원칙
주요 목표코드 이해도 향상
코드 변경 용이성 증대
코드 테스트 용이성 증대
유지 보수성 향상
확장성 향상
각 원칙 상세 설명
단일 책임 원칙클래스는 변경해야 할 이유가 하나여야 한다. 즉, 클래스는 단 하나의 책임만을 가져야 한다.
개방-폐쇄 원칙확장에는 열려 있고, 수정에는 닫혀 있어야 한다. 새로운 기능을 추가할 때 기존 코드를 수정하지 않고 확장할 수 있어야 한다.
리스코프 치환 원칙하위 타입은 언제나 자신의 기반 타입으로 교체할 수 있어야 한다.
인터페이스 분리 원칙클라이언트는 자신이 사용하지 않는 메서드에 의존하도록 강요받아서는 안 된다. 인터페이스를 작게 유지하고, 클라이언트가 필요한 메서드만 제공해야 한다.
의존관계 역전 원칙고수준 모듈은 저수준 모듈에 의존해서는 안 된다. 둘 다 추상화에 의존해야 한다.
추상화는 세부 사항에 의존해서는 안 된다. 세부 사항이 추상화에 의존해야 한다.
관련 정보
관련 서적의 Design Principles and Design Patterns
의 Principles Of OOD
Steve Fenton의 Pro TypeScript: Application-Scale JavaScript Development
관련 영상Sandi Metz의 SOLID Object-Oriented Design

2. SOLID 원칙

SOLID는 객체 지향 프로그래밍 및 설계의 다섯 가지 기본 원칙을 나타내는 두문자어이다. 이 원칙들은 소프트웨어를 더 이해하기 쉽고, 유연하며, 유지보수하기 쉽게 만들기 위해 제시되었다.

두문자약어개념
SSRP한 클래스는 하나의 책임만 가져야 한다.
OOCP소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
LLSP프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
IISP특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.[25]
DDIP프로그래머는 추상화에 의존해야지, 구체화에 의존하면 안된다.[25]



SOLID는 다음 원칙들로 구성된다.



각 원칙에 대한 자세한 내용은 하위 섹션을 참고한다.

2. 1. 단일 책임 원칙 (Single Responsibility Principle, SRP)

단일 책임 원칙(SRP)은 "어떤 클래스가 변경되어야 하는 이유는 단 하나여야 한다"[1]는 원칙이다. 즉, 모든 클래스는 하나의 책임만 가져야 한다.[2]

이는 모든 클래스가 각각 하나의 책임(responsibility영어)만 가져야 한다는 의미이다. 여기서 책임은 제공 기능과 같은 의미로, 클라이언트에게 특정 기능을 제공하는 역할(role영어)을 하는 행위자(actor영어)로서의 클래스에 초점을 맞춘다.

이 원칙에 따르면 각 서비스는 하나의 기능 또는 하나의 역할만 가질 수 있으며, 클라이언트는 기능별로 담당 서비스를 변경하게 된다.

2. 1. 1. 중요성

SOLID 원칙을 따르면 소프트웨어의 유지보수성, 테스트 용이성, 그리고 유연성을 향상시킬 수 있다.

  • 유지보수성: 클래스가 단일하고 명확하게 정의된 책임을 가질 때 이해하고 수정하기가 더 쉬워진다.
  • 테스트 용이성: 단일 초점을 가진 클래스에 대한 단위 테스트를 작성하기가 더 쉽다.
  • 유연성: 한 책임에 대한 변경 사항이 시스템의 관련 없는 부분에 영향을 미치지 않는다.[2]


단일 책임 원칙(SRP)은 "클래스가 변경되어야 하는 이유는 하나 이상이어야 한다."[17]라는 말로 요약할 수 있다. 이는 모든 클래스가 각각 하나의 책임만을 가져야 한다는 의미이다. 여기서 책임은 제공하는 기능과 같은 의미로 사용된다. 이 원칙은 특정 기능을 제공하는 역할(role)을 하는 행위자(actor)로서의 클래스에 초점을 맞춘다.

이 원칙에 따르면 각 서비스는 하나의 기능 또는 하나의 역할만 가질 수 있다. 클라이언트는 기능별로 담당 서비스를 변경하게 된다.

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

소프트웨어 개체는 확장에 열려 있어야 하고, 수정에는 닫혀 있어야 한다는 원칙이다.[3] 즉, 기존의 코드를 변경하지 않으면서도 기능을 추가하거나 변경할 수 있도록 설계해야 한다.

Open/closed principle|개방-폐쇄 원칙영어에 따르면, 소프트웨어 실체(클래스, 모듈, 함수 등)는 확장에 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다.[18] 이 원칙에서 인터페이스는 그 구성이 불변하게 되고, 서비스는 구성의 변화가 허용된다.

2. 2. 1. 중요성

SOLID 원칙은 소프트웨어의 확장성, 안정성, 유연성을 높이는 데 중요한 역할을 한다.

  • 확장성: 기존 코드를 수정하지 않고도 새로운 기능을 추가할 수 있다.
  • 안정성: 변경 시 버그가 발생할 위험을 줄여준다.
  • 유연성: 변화하는 요구사항에 더 쉽게 적응할 수 있다.


Open/closed principle|개방-폐쇄 원칙영어에 따르면, 소프트웨어 실체(클래스, 모듈, 함수 등)는 확장에 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다.[18] 이 원칙 하에서 인터페이스는 그 구성이 불변하게 되고, 서비스는 구성의 변화가 허용된다. 서비스의 구성 변화는 상속에 의한 서브클래스 정의로 이루어지는 것이 일반적이다.

2. 3. 리스코프 치환 원칙 (Liskov Substitution Principle, LSP)

리스코프 치환 원칙(LSP)은 "프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다"는 원칙이다. 계약에 의한 설계를 참고하라. 구체적으로는 "[기저 클래스]에 대한 포인터나 참조를 사용하는 함수는 파생 클래스의 객체를 해당 사실을 알지 못한 채 사용할 수 있어야 한다."[4]

2. 3. 1. 중요성

다형성은 코드를 더 유연하고 재사용 가능하게 만들어 다형적 행동을 사용할 수 있게 한다. SOLID 원칙은 서브클래스가 슈퍼클래스에 의해 정의된 계약을 준수하도록 보장하여 신뢰성을 높인다.[4] 또한 슈퍼클래스 객체를 서브클래스 객체로 대체해도 프로그램이 손상되지 않도록 보장하여 예측 가능성을 높인다.[4] 즉, 기본 클래스에 대한 포인터나 참조를 사용하는 함수는 파생 클래스의 객체를 해당 사실을 알지 못하고 사용할 수 있어야 한다.[19]

이 원칙 하에서 클라이언트는 하나의 인터페이스를 통해 다양한 서비스 클래스를 이용하게 된다.

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

인터페이스 분리 원칙(ISP)은 "클라이언트는 사용하지 않는 인터페이스에 의존하도록 강요받아서는 안 된다"[5][10]는 원칙이다. 즉, 특정 클라이언트를 위한 여러 개의 인터페이스가 하나의 범용 인터페이스보다 낫다.[20]

2. 4. 1. 중요성

SOLID 원칙은 소프트웨어의 결합도를 감소시켜 코드를 더 모듈화하고 유지 관리하기 쉽게 만든다.[20] 인터페이스를 더 세분화하여 구현함으로써 유연성을 높이고, 클라이언트가 사용하지 않는 메서드에 의존할 필요가 없어져 불필요한 의존성을 방지한다.[20] 이러한 원칙에 따라 인터페이스는 다양하게 기능이 분화되어 세부적인 용도별로 정의된다.

2. 5. 의존관계 역전 원칙 (Dependency Inversion Principle, DIP)

의존성 역전 원칙(Dependency Inversion Principle, DIP)은 프로그래머가 구체적인 것에 의존하는 것이 아니라 추상화에 의존해야 한다는 원칙이다.[25] 고수준 모듈은 하위 모듈에서 아무것도 가져오면 안 되며, 둘 다 구체화가 아닌 추상화(예: 인터페이스)에 의존해야 한다.[21]

이 원칙은 믹스인을 모티브로 하여 의존성 주입 등의 기반이 되고 있다. 이 원칙 하의 클라이언트는 전문 기능이 분리된 모듈이 되며, 하위 모듈은 전문 기능의 취급 방식을 변경한 것이 된다. 전문 기능이란 클라이언트가 인터페이스를 통해 이용하는 서비스이며, 상위 클라이언트와 하위 클라이언트는 모두 전문 기능 인터페이스에 의존하게 된다. 여기서 클라이언트는 구체화이며, 인터페이스는 추상이다.

2. 5. 1. 중요성

SOLID 원칙은 소프트웨어 개발에서 다음과 같은 중요한 이점을 제공한다.

  • 느슨한 결합: 모듈 간의 의존성을 줄여 코드를 더 유연하게 만들고 테스트하기 쉽게 만든다.
  • 유연성: 클라이언트에 영향을 주지 않고 구현을 변경할 수 있도록 한다.
  • 유지보수성: 코드를 이해하고 수정하기 쉽게 만든다.[6][10]


고수준 모듈은 하위 모듈에서 아무것도 가져오면 안 된다. 둘 다 구체화가 아닌 추상화(예: 인터페이스)에 의존해야 한다.[21]

이 원칙은 믹스인을 모티브로 하여 의존성 주입 등의 기반이 되고 있다.

이 원칙 하의 클라이언트는 전문 기능이 분리된 모듈이 된다. 그 하위 모듈은 전문 기능의 취급 방식을 변경한 것이 된다. 전문 기능이란, 클라이언트가 인터페이스를 통해 이용하는 서비스이며, 상위 클라이언트와 하위 클라이언트는 모두 전문 기능 인터페이스에 의존하게 된다. 여기서 클라이언트는 구체화이며, 인터페이스는 추상이다.

3. SOLID 원칙의 기원

로버트 C. 마틴[7][8][9]은 2000년 논문 ''Design Principles and Design Patterns''에서 이 원칙들을 소개했다.[8][10] ''SOLID'' 약어는 2004년경 마이클 페더스에 의해 만들어졌다.[11]

4. 관련 개념 및 원칙

참조

[1] 웹사이트 Single Responsibility Principle http://www.objectmen[...]
[2] 서적 Agile Software Development, Principles, Patterns, and Practices https://books.google[...] Prentice Hall
[3] 웹사이트 Open/Closed Principle http://www.objectmen[...]
[4] 웹사이트 Liskov Substitution Principle http://www.objectmen[...]
[5] 웹사이트 Interface Segregation Principle http://www.objectmen[...] 1996
[6] 웹사이트 Dependency Inversion Principle http://www.objectmen[...]
[7] 웹사이트 Principles Of OOD http://butunclebob.c[...] 2014-07-17
[8] 웹사이트 Getting a SOLID start https://sites.google[...] 2013-08-19
[9] Youtube SOLID Object-Oriented Design https://www.youtube.[...] 2019-08-13
[10] 웹사이트 Design Principles and Design Patterns http://www.objectmen[...]
[11] 서적 Clean Architecture: A Craftsman's Guide to Software Structure and Design https://books.google[...] Pearson
[12] 웹사이트 Design Principles and Design Patterns http://www.objectmen[...] 2000
[13] 웹사이트 Principles Of OOD http://butunclebob.c[...] 2014-07-17
[14] 웹사이트 Getting a SOLID start https://sites.google[...] 2013-08-19
[15] 웹사이트 SOLID Object-Oriented Design https://www.youtube.[...] 2009-05
[16] 서적 Pro TypeScript: Application-Scale JavaScript Development https://books.google[...]
[17] 웹사이트 Single Responsibility Principle http://www.objectmen[...] 2015-09-05
[18] 웹사이트 Open/Closed Principle http://www.objectmen[...] 2015-09-05
[19] 웹사이트 Liskov Substitution Principle http://www.objectmen[...] 2015-09-05
[20] 웹사이트 Interface Segregation Principle http://www.objectmen[...] 2015-09-05
[21] 웹사이트 Dependency Inversion Principle http://www.objectmen[...] 2015-09-05
[22] 웹사이트 Principles Of OOD http://butunclebob.c[...]
[23] 웹사이트 Getting a SOLID start. https://sites.google[...]
[24] 간행물 SOLID Object-Oriented Design http://www.confreaks[...] 2009-05
[25] 간행물 Design Principles and Design Patterns http://www.objectmen[...] 20150906155800


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com