코이팅

객체지향 프로그래밍의 5가지 설계 원칙, SOLID 본문

CS

객체지향 프로그래밍의 5가지 설계 원칙, SOLID

코이팅 2023. 1. 19. 17:00
728x90
반응형

1. 객체지향 프로그래밍의 5가지 설계 원칙, SOLID란?

1) SOLID의 개념

출처 : https://didemeren.medium.com/solid-principles-in-practice-a9771a746f6c

 

'SOLID'란 객체 지향 프로그래밍을 하면서 지켜야하는 5대 원칙으로

- SRP(단일 책임 원칙),
- OCP(개방-폐쇄 원칙),
- LSP(리스코프 치환 원칙),
- ISP(인터페이스 분리 원칙),

- DIP(의존 역전 원칙)

의 앞글자를 따서 만들어졌습니다. SOLID 원칙을 철저히 지키면 시간이 지나도 변경이 용이하고, 유지보수와 확장이 쉬운 소프트웨어를 개발하는데 도움이 되는 것으로 알려져있습니다. 응집도를 높이고, 결합도를 낮추는 원칙을 객체지향의 관점에서 재정립한 설계 원칙입니다.

 

**[응집도와 결합도]

- 응집도 : 모듈 내부 요소들의 연관 정도
(기능적 응집도 > 순차적 응집도 > 통신적 응집도 > 절차적 응집도 > 일시적 응집도 > 논리적 응집도 > 우연적 응집도)

 

- 결합도 : 모듈 간 상호 의존 정도
(자료 결합도 < 스탬프 결합도 < 제어 결합도 < 외부 결합도 < 공통 결합도 < 내용 결합도)

 

모듈은 특정 기능별로 나누어진 프로그램의 부분으로써 작게는 클래스, 크게는 소프트웨어까지를 의미합니다. 좋은 소프트웨어는 높은 응집도와 낮은 결합도를 가집니다. 이렇게 되면 높은 재사용성과, 쉬운 수정 및 유지보수가 가능합니다. 

[ 단일 책임의 원칙(SRP, Single Responsibility Principle) ]

출처 :&nbsp;https://minkwon4.tistory.com/281

한 클래스는 하나의 책임만 가져야 한다.

SRP는 하나의 모듈이 하나의 책임을 가져야 한다는 모호한 원칙으로 해석하면 안됩니다. 대신 모듈이 변경되는 이유가 한가지여야 함으로 받아들여야 합니다. 여기서 변경의 이유가 한가지라는 것은 해당 모듈이 여러 대상 또는 액터들에 대해 책임을 가져서는 안되고, 오직 하나의 액터에 대해서만 책임을 져야 한다는 것을 의미합니다.

[ 개방 폐쇄 원칙 (Open-Closed Principle, OCP) ]

출처 :&nbsp;https://minkwon4.tistory.com/281

개방 폐쇄 원칙(Open-Closed Principle, OCP)은 확장에 대해 열려있고 수정에 대해서는 닫혀있어야 한다는 원칙으로, 각각이 갖는 의미는 다음과 같습니다.

- 확장에 대해 열려 있다: 요구사항이 변경될 때 새로운 동작을 추가하여 애플리케이션의 기능을 확장할 수 있습니다.
- 수정에 대해 닫혀 있다: 기존의 코드를 수정하지 않고 애플리케이션의 동작을 추가하거나 변경할 수 있습니다.

[ 리스코프 치환 원칙 (Liskov Substitution Principle, LSP) ]

출처 :&nbsp;https://minkwon4.tistory.com/281

리스코프 치환 원칙은 1988년 바바라 리스코프가 올바른 상속 관계의 특징을 정의하기 위해 발표한 것으로, 위 타입은 상위 타입을 대체할 수 있어야 한다는 것입니다.

즉, 해당 객체를 사용하는 클라이언트는 상위 타입이 하위 타입으로 변경되어도, 차이점을 인식하지 못한 채 상위 타입의 퍼블릭 인터페이스를 통해 서브 클래스를 사용할 수 있어야 한다는 것입니다.

[ 인터페이스 분리 원칙 (Interface segregation principle, ISP) ]

출처 :&nbsp;https://minkwon4.tistory.com/281

객체가 충분히 높은 응집도의 작은 단위로 설계됐더라도, 목적과 관심이 각기 다른 클라이언트가 있다면 인터페이스를 통해 적절하게 분리해줄 필요가 있는데, 이를 인터페이스 분리 원칙이라고 부릅니다.

즉, 인터페이스 분리 원칙이란 클라이언트의 목적과 용도에 적합한 인터페이스 만을 제공하는 것입니다. 인터페이스 분리 원칙을 준수함으로써 모든 클라이언트가 자신의 관심에 맞는 퍼블릭 인터페이스(외부에서 접근 가능한 메세지)만을 접근하여 불필요한 간섭을 최소화할 수 있으며, 기존 클라이언트에 영향을 주지 않은 채로 유연하게 객체의 기능을 확장하거나 수정할 수 있습니다.

인터페이스 분리 원칙을 지킨다는 것은 어떤 구현체에 부가 기능이 필요하다면 이 인터페이스를 구현하는 다른 인터페이스를 만들어서 해결할 수 있습니다. 예를 들어 파일 읽기/쓰기 기능을 갖는 구현 클래스가 있는데 어떤 클라이언트는 읽기 작업 만을 필요로 한다면 별도의 읽기 인터페이스를 만들어 제공해주는 것입니다.

[ 의존 역전 원칙 (Dependency Inversion Principle, DIP) ]

출처 :&nbsp;https://minkwon4.tistory.com/281

 

의존 역전 원칙이란 고수준 모듈은 저수준 모듈의 구현에 의존해서는 안 되며, 저수준 모듈이 고수준 모듈에 의존해야 한다는 것입니다. 객체 지향 프로그래밍에서는 객체들 사이에 메세지를 주고 받기 위해 의존성이 생기는데, 의존성 역전의 원칙은 올바른 의존 관계를 위한 원칙에 해당된다. 여기서 각각 고수준 모듈과 저수준 모듈이란 다음을 의미합니다다.

- 고수준 모듈: 입력과 출력으로부터 먼(비즈니스와 관련된) 추상화된 모듈
- 저수준 모듈: 입력과 출력으로부터 가까운(HTTP, 데이터베이스, 캐시 등과 관련된) 구현 모듈

의존 역전 원칙이란 결국 비즈니스와 관련된 부분이 세부 사항에는 의존하지 않는 설계 원칙을 의미합니다.

 

 

[참고]

https://mangkyu.tistory.com/194

https://minkwon4.tistory.com/281

728x90
반응형

'CS' 카테고리의 다른 글

OAuth2.0란?  (0) 2023.01.23
REST, REST API, RESTful  (0) 2023.01.18
비동기 통신 Ajax와 Fetch API  (0) 2023.01.17
스프링 배치(Spring Batch)와 스케쥴러(Scheduler)  (0) 2023.01.17
시간복잡도(Time Complexity)  (0) 2023.01.15
Comments