객체 지향 설계 5원칙 - SOLID

주짱·2022년 5월 31일
106

디자인 패턴

목록 보기
1/4
post-thumbnail

일반적으로 프로그래머가 개발을 하게 되면 그 당시에는 기억할 수 있지만 시간이 지난 후에 다시 코드를 보게 되거나 다른 개발자가 코드를 볼 때, 충분한 설명이 없다면 이해하기 어렵고 유지 보수에도 어려움을 겪게 된다. 하지만, 객체지향 디자인 원리들을 사용하면 좀 더 유지보수하기 쉽고, 확장이 쉬운 소프트웨어를 만들 수 있다. 2000년 대 초반에 로버트 마틴은 객체지향 프로그래밍 및 설계의 5가지 원칙을 정의했었다. 이 5가지 기본 원칙을 마이클 페더스가 원칙의 앞 대문자만 따서 SOLID라고 명명되었다.


🔶SRP - 단일 책임 원칙
(Single Responsibility Priniciple)

There should never be more than one reason for a class to change.

👉 여기서 말하는 책임이란, 기능 또는 변화의 축(axis of change) 즉, '소프트웨어를 구성하는 설계 부품인 클래스나 함수 등은 단 하나의 기능만을 가져야 한다' 는 의미이다. 만약 하나의 함수가 소프트웨어 내에서 책임져야하는 부분이 많을 경우, 섣불리 내부를 변경하기도 어렵고, 이는 다른 요소들과도 연계가 강하다는 의미이기 때문에 결과적으로 유지보수 비용이 증가하게 된다. 따라서, 어떠한 클래스를 변경하기 위해서는 반드시 바꾸려는 이유는 한 가지 뿐이여야만 한다. 이 원리를 적용하면 무엇보다도 책임 영역이 확실해지기 때문에 한 책임의 변경에서 다른 책임의 변경으로의 연쇄작용에서 자유로울 수 있을 뿐더러 코드의 가독성 향상, 유지보수 용이라는 이점까지 누릴 수 있다.


🔶OCP - 개방∙폐쇄 원칙
(Open Closed Principle)

You should be able to extend a classes behavior, without modifying it.

👉 버틀란트 메이어(Bertrand Meyer) 박사가 1998년 객체지향 소프트웨어 설계 라는 책에서 정의한 내용으로 소프트웨어의 구성요소(컴포넌트,클래스,모듈,함수)는 확장에는 열려있고, 변경에는 닫혀있어야 한다 는 원리이다. 이것은 변경을 위한 비용은 가능한 줄이고 확장을 위한 비용은 극대화 해야 한다는 의미로, 요구사항의 변경이나 추가사항이 발생하더라도, 기존 구성요소는 수정이 일어나지 말아야 하며, 기존 구성요소를 쉽게 확장해서 재사용할 수 있어야 한다는 뜻이다.


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

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

👉 이 원칙은 MIT 컴퓨터 사이언스 교수인 리스코프가 제안한 설계 원칙으로, 부모 클래스와 자식 클래스 사이에는 일관된 행위가 있어야 한다는 원칙이다. 즉, 자식 클래스는 부모 클래스에서 가능한 행위를 수행해야 하며, 객제 지향 프로그래밍에서는 부모 클래스의 인스턴스 대신 자식 클래스의 인스턴스를 사용해도 문제가 없다는 것 을 의미한다.


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

Clients should not be forced to depend upon interfaces that they do not use.

👉 한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다는 원칙 이다. 즉, 어떤 클래스가 다른 클래스에 종속될 때에는 가능한 최소한의 인터페이스만을 사용해야 한다. 이를 하나의 일반적인 인터페이스보다는 여러 개의 구체적인 인터페이스가 낫다 라고 정의 할 수도 있다. 이 원칙을 적용하여 설계하면, 시스템의 내부 의존성을 약화시켜 리팩토링, 수정, 재배포를 쉽게 할 수 있는 이점이 생긴다.


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

A. High Level modules should not depend upon low level modules. Both should depend upon abstractions.
B. Abstractions should not depend upon details. Details should depend upon abstractions.

👉 의존 관계의 역전이란 구조적 디자인에서 발생하던 하위 모듈의 변경이 상위 레벨 모듈의 변경을 요구하는 위계관계를 끊는 의미의 역전이다. 실제 사용 관계는 바뀌지 않으며, 추상을 매개로 메시지를 주고 받음으로써 관계를 최대한 느슨하게 만드는 원칙이다. 이는 의존관계를 맺을 때, 변화하기 쉬운 것보다는 변화하기 어려운 것에 의존해야 한다는 의미이다. 여기서 말하는 변화하기 쉬운 것은 객체지향의 관점에서 보면 구체화 된 클래스를 의미하고, 변화하기 어려운 것이란 추상클래스나 인터페이스를 의미한다. 결과적으로 의존관계를 맺을 때에는 추상클래스나 인터페이스와 관계를 맺는다 고 정리할 수 있다. 이 원칙을 적용하면 복잡한 컴포넌트간의 커뮤니케이션 관계를 단순화하고 컴포넌트 간의 커뮤니케이션을 효율적이게 한다.


[참조문헌]
https://www.nextree.co.kr/p6960/

profile
개발의, 개발에 의한, 개발을 위한 ✍

4개의 댓글

comment-user-thumbnail
2022년 6월 7일

아침부터 좋은 글에 무릎을 탁! 치고 갑니다!

답글 달기
comment-user-thumbnail
2022년 6월 7일

와... 예시가 장난 아니게 이해 잘되네요 😋
좋은 글 감사합니다 !!

답글 달기
comment-user-thumbnail
2022년 6월 7일

멋진 개발자 ;) ~!~!

답글 달기
comment-user-thumbnail
2022년 6월 7일

잘 읽고갑니다.
좋은 정보 감사합니다~

답글 달기