Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
Tags
- redis
- NestJS
- 스프링부트
- Dev-Matching
- 프론트엔드 과제
- this
- api 비동기처리
- 파일 url
- 모던 자바스크립트
- 검색
- 유효시간 설정 url
- 음악 url 파일 다운로드
- 프론트엔드
- 자바스크립트
- TypeORM
- 우아한테크코스
- oauth
- bucket4j
- Deep Dive
- api 요청 수 제한
- 타입스크립트
- invalid_grant
- AWS
- 프로그래머스
- concurrency limit
- compateto
- 우아한 테크코스
- 프리코스
- 딥다이브
- 코멘토 #코멘토실무PT #실무PT후기 #실무강의 #리액트강의 #웹프로그래밍 #react #웹개발실무
Archives
- Today
- Total
개발 알다가도 모르겠네요
SOLID 설계원칙 본문
728x90
SOLID란?
로버트 마틴이 주장한 다섯 가지 설계원칙을 말함.
- SRP(단일 책임 원칙, Single Responsibility Principle)
- OCP(개방 폐쇄 원칙, Open Closed Principle)
- LSP(리스코프의 대입 원칙, Liskov Substitution Principle)
- ISP(인터페이스 분리 원칙, Interface Segregation Principle)
- DIP(의존성 역전 원칙, Dependency Inversion Principle)
SRP (Single Responsibility Principle)
- 단일 책임 원칙 (클래스는 단 하나의 책임만을 가지도록 설계해야 한다는 의미)
- 책임은 보통 「해야 하는 것」으로 간주. 클래스에 책임을 할당할 때 당연히 그 책임을 수행해야 하는 클래스에 할당해야 함.
- 책임은 「변경 이유」로 해석할 수 있음. 클래스가 변경되어야 하는 이유는 하나만 되도록 설계.
OCP (Open Closed Principle)
- 개방 폐쇄의 원칙
- OCP는 기존의 코드를 변경하지 않으면서 새로운 기능을 추가할 수 있도록 설계하는 원칙.
LSP (Liskov Substitution Principle)
- 일반화 관계를 적절하게 사용했는지 점검하는 원칙
- 슈퍼 클래스의 인스턴스(부모) 대신에 파생 클래스의 인스턴스(자식)로 대체해도 프로그램의 의미는 변화되지 않도록 설계.
- 재정의가 이뤄질 때, 자식클래스가 부모클래스보다 많은 기능을 가진다면 일반화 구조가 성립.
ISP (Interface Segregation Principle)
- Clients should not be forced to depend upon interfaces that they do not use.
-
인터페이스를 클라이언트에 특화되도록 분리시키라는 설계 원칙 (fat interface -> small interface)
-
클라이언트의 관점에서 클라이언트 자신이 이용하지 않는 기능에는 영향을 받지 않아야 한다는 내용이 담겨 있음.
- 온갖 연산을 다 가진 인터페이스는 클라가 이용하지 않는 기능에 영향 줌.
DIP (Dependency Inversion Principle)
- 의존 관계를 맺을 때 변화하기 쉽고, 자주 되는 것보다는 변화하기가 어려운 것, 변화가 거의 되지 않는 것에 의존하라는 원칙.
-
객체지향 관점에서 변하기 어려운 추상적인 것들을 표현하는 수단으로 추상 클래스와 인터페이스가 있음.
-
DIP를 만족하기 위해선 어떤 클래스가 도움을 받을 때 구체적인 클래스 보다는 인터페이스나 추상 클래스에 의존관계를 맺도록 설계.
- 상위 모듈은 하위 모듈에 의존하면 안되며, 두 모듈 모두 다른 추상화된 것에 의존해야함.
- 추상화된 것은 구체적인 것에 의존하면 안되며, 구체적인 것이 추상화된 것에 의존해야함.
정책, 전략과 같은 어떤 큰 흐름이나 개념 같은 추상적인 것은 변하기 어려운 것에 해당하고
구체적인 방식, 사물 등과 같은 것은 변하기 쉬운 것에 해당.
'디자인패턴' 카테고리의 다른 글
Command Pattern 을 알아보자 (0) | 2021.12.11 |
---|---|
Strategy Pattern 을 알아보자 (0) | 2021.12.11 |
Builder Pattern 을 알아보자 (0) | 2021.12.10 |
Singleton Pattern 을 알아보자 (0) | 2021.12.10 |
객체지향의 원리 (0) | 2021.12.09 |