728x90
CS
객체 지향 설계의 5가지 원칙 - S.O.L.I.D
- SOLID 원칙이란 객체 지향 설계에서 지켜줘야 할 5개의 소프트웨어 개발 원칙을 말한다.
- SRP(Single Responsibility Principle) 단일 책임 원칙
- OCP(Open Closed Principle) 개방 폐쇄 원칙
- LSP(Listov Substitution Principle) 리스코프 치환 원칙
- ISP(Interface Segregation Principle) 인터페이스 분리 원칙
- DIP(Dependency Inversion Principle) 의존 역전 원칙
- SOLID 설계 원칙은 OOP의 4가지 특징(추상화, 상속, 다형성, 캡슐화)와 더불어, 객체 지향 프로그래밍의 단골 질문 중 하나이다.
- 좋은 소프트웨어란 변화에 대응을 잘 하는 것을 말한다. 좋은 설계란 시스템에 새로운 요구사항이나 변경사항이 있을 떄, 영향을 받는 범위가 적은 구조를 말한다. 그래서 시스템에 예상하지 못한 변경사항이 발생하더라도, 유연하게 대처하고 이후에 확장성이 있는 시스템 구조를 만들 수 있다.
- 즉, SOLID 객체 지향 원칙을 적용하면 코드를 확장하고 유지 보수 관리하기가 더 쉬워지며, 불필요한 복잡성을 제거해 리팩토링에 소요되는 시간을 줄임으로써 프로젝트 개발의 생산성을 높일 수 있다.
- SOLID는 어떤 특정 프로그래밍 언어 혹은 프레임워크를 위해 만든 원칙이 아니다. 라이브러리의 패턴도 아니며, 특정 기술에 국한되지 않는다. 그래서 선호하는 프로그래밍 언어나 프레임워크에 원칙을 자유롭게 적용할 수도 있다.
단일 책임 원칙 - SRP(Single Responsibility Principle)
- 단일 책임 원칙은 클래스(객체)는 단 하나의 책임만 가져야 한다는 원칙이다.
- 여기서 책임은 하나의 기능 담당으로 볼 수 있다.
- 즉, 하나의 클래스는 하나의 기능을 담당하여 하나의 책임을 수행하는데 집중되도록 클래스를 따로 여러 개 설계하라는 원칙이다.
- SRP 원칙을 따름으로 한 책임의 변경으로부터 다른 책임의 변경으로의 연쇄작용을 극복할 수 있게 된다.
- 최종적으로 단일 책임 원칙의 목적은 프로그램의 유지보수성을 높이기 위한 설계 기법이다.
개방 폐쇄 원칙 - OCP(Open Closed Principle)
- OPC 원칙은 클래스는 확장에 열려있어야 하며, 수정에는 닫혀있어야 한다를 뜻한다.
- 기능 추가 요청이 오면 클래스를 확장을 통해 손쉽게 구현하면서, 확장에 따른 클래스 수정은 최소화 하도록 프로그램을 작성해야 하는 설계 기법이다.
- 확장에 열려있다.
- 새로운 변경 사항이 발생했을 때 유연하게 코드를 추가함으로써 큰 힘을 들이지 않고 애플리케이션의 기능을 확장할 수 있다.
- 변경에 닫혀있다.
- 새로운 변경 사항이 발생했을 때 객체를 직접적으로 수정을 제한한다.
- 확장에 열려있다.
- OCP 원칙은 추상화 사용을 통한 관계 구축의 권장을 의미하는 것이다. 즉, 다형성과 화갖ㅇ을 가능케 하는 객체지향의 장점을 극대화하는 기본적인 설계 원칙이다.
리스코프 치환 원칙 - LSP(Liskov Subsititution Principle)
- LSP 원칙은 서브 타입은 언제나 기반(부모) 타입으로 교체할 수 있어야 한다는 원칙이다. 쉽게말하면 LSP는 다형성 원리를 이용하기 위한 원칙 개념으로 보면된다.
- 리스코프 치환 원칙이란, 다형성의 특징을 이용하기 위해 상위 클래스 타입으로 객체를 선언하여 하위 클래스의 인스턴스를 받으면, 업캐스팅된 상태에서 부모의 메서드를 사용해도 동작이 의도대로 흘러가야 하는 것을 의미한다.
- 따라서 기본적으로 LSP 원칙은 부모 메서드의 오버라이딩을 조심스럽게 따져가며 해야한다.
인터페이스 분리 원칙 - ISP(Interface Segregation Principle)
- ISP 원칙은 인터페이스를 각각 사용에 맞게 끔 잘게 분리해야한다는 설계 원칙이다.
- SRP 원칙이 클래스의 단일 책임을 강조한다면, ISP는 인터페이스의 단일 책임을 강조하는 것으로 보면 된다.
- 즉, SRP 원칙의 목표는 클래스 분리를 통하여 이루어진다면, ISP 원칙은 인터페이스 분리를 통해 설계하는 원칙
- ISP 원칙은 인터페이스를 사용하는 클라이언트를 기준으로 분리함으로써, 클라이언트의 목적과 용도에 적합한 인터페이스 만을 제공하는 것이 목표이다.
- 다만 ISP 원칙의 주의해야 할 점은 한 번 인터페이스를 분리하여 구성해놓고 나중에 무언가 수정사항이 생겨서 또 인터페이스들을 분리하는 행위를 가하지 말아야 한다.
의존 역전 원칙 - DIP(Dependency Inversion Principle)
- DIP 원칙은 어떤 Class를 참조해서 사용해야 하는 상황이 생긴다면, 그 Class를 직접 참조하는 것이 아니라 그 대상의 상위 요소 ( 추상 클래스 or 인터페이스)로 참조하라는 원칙이다. 구현 클래스에 의존하지 말고, 인터페이스에 의존하라는 뜻이다.
- 의존 관계를 맺을 때 변화하기 쉬운 것 또는 자주 변화하는 것보다는, 변화하기 어려운 것 거의 변화가 없는것에 의존해야 한다.
참조
https://inpa.tistory.com/entry/OOP-💠-객체-지향-설계의-5가지-원칙-SOLID
C++
- 메모리를 관리하는 문제는 언제나 중요한 문제이다. 프로그램이 정확하게 실행되기 위해서는 컴파일 시에 모든 변수의 주소값이 확정 되어야만 했다. 하지만, 이를 위해서는 프로그램에 많은 제약이 따르기 때문에 프로그램 실행 시에 자유롭게 할당하고 해제할 수 있는 힙(heap)이라는 공간이 따로 생겼다.
- 하지만 이전에 컴파일러에 의해 어느정도 안정성이 보장되는 스택(stack) 과는 다르게 힙은 사용자가 스스로 제어해야 하는 부분인 만큼 책임이 따른다.
- C언어에서는 malloc 과 free 함수를 지원하여 힙 상에서 메모리 할당을 지원했다. C++에서도 마찬가지로 malloc과 free 함수를 사용할 수 있다.
- 하지만, 언어 차원에서 지원하는 것으로 바로 new 와 delete 라고 할 수 있다. new는 메모리를 할당하고 delete는 메모리를 해제한다.
#include <iostream>
int main() {
int* p = new int;
*p = 10;
std::cout << *p << std::endl;
delete p;
return 0;
}
- 지역 변수를 무리하게 delete로 해제해버리려 한다면 heap이 아닌 공간을 해제하려고 한다는 경고 메세지가 나타나게 된다.
728x90
'Study > TIL(Today I Learned)' 카테고리의 다른 글
24.08.30 CS, C++ (0) | 2024.08.30 |
---|---|
24.08.29 CS, C++ (0) | 2024.08.29 |
24.08.26 CS, C++ (0) | 2024.08.26 |
24.08.23 CS (0) | 2024.08.23 |
24.08.22 CS, C++ (0) | 2024.08.22 |