[C++] 용어 정리(1) 객체지향 철학, 객체지향 디자인 원칙(SOLID)

 

 

 

여러 가지 용어

믹스인 클래스: 믹스인(mixin) 클래스는 다중 상속과 같지만 의미는 전혀 다르다. 믹스인 클래스는 '이 클래스가 할 수 있는 일이 또 뭐가 있나?' 란 질문에 '~도 할 수 있다'라고 답하는 역할을 한다. 믹스인 클래스는 is-a 관계를 완전히 구현하지 않고도 기능을 추가할 때 사용한다. 일종의 '공유' 관계라 볼 수 있다.

 

라이브러리: XML을 파싱 하거나 암호화와 같은 특정한 작업을 처리하는 데 필요한 코드를 한데 묶은 것이다. 스레드와 동기화

를 지원하거나 네트워킹이나 그래프 작업에 특화된 기능도 라이브러리로 구성하는 경우가 많다.

 

프레임워크: 디자인할 프로그램의 기반이 되는 코드를 모아둔 것이다. 예를 들어 MFC(Microsoft Foundation Class)

라이브러리는 마이크로소프트 윈도우용 GUI(Graphical User Interface) 애플리케이션을 개발하기 위한 프레임워크다.

프레임워크에 따라 프로그램의 구성 방법까지도 제시한다.

 

NOTE: 프로그램은 라이브러리를 활용하고, 프레임워크에 맞게 작성한다. 다시 말해 라이브러리는 특정한 기능을 제공하는 반면 프레임워크는 프로그램의 디자인과 구조에 대한 토대를 제공한다.

 

API: API(Application Programming Interface)는 특정한 기능을 수행하는 코드나 라이브러리에 대한 인터페이스다.

네트워크 프로그래밍에서 많이 사용하는 소켓 API를 예로 들 수 있는데, 이 API는 소켓 라이브러리를 직접 제공하지 않고 

이를 사용하기 위한 인터페이스만 제공한다.

 

NOTE: API와 라이브러리를 혼용하는 경우가 많은데, 둘은 서로 다른 개념이다. 라이브러리는 구현을 의미하는 반면

API는 이러한 라이브러리를 외부에 제공하기 위한 인터페이스를 가리킨다.

 

 

객체지향 철학

객체지향 철학: 절차형 접근 방식이 '이 프로그램이 무슨 일을 하는가?'라는 질문을 토대로 접근하는데 반해 객체지향 접근 방식은 ' 이 현실세계의 어떤 대상을 모델링하는가?'라는 관점에서 접근한다. 객체 지향 프로그래밍에서는 프로그램을 작업 단위가 아니라 물리적인 대상에 대한 모델 단위로 나눈다. 처음에는 다소 추상적인 것 같지만 물리적인 대상을 클래스, 컴포넌트, 프로퍼티(속성), 동작의 관점에서 분석하다 보면 와 닿게 된다.

 

클래스: 클래스란 개념을 적용하면 구체적인 대상과 그 대상에 대한 정의를 구분할 수 있다. 

누가 '오렌지가 뭐냐'라고 물을 때 오렌지는 나무에서 자라고 주항 색을 띠고 독특항 향과 맛을 내는 과일의 한 종류(클래스)라고 답할 수 있다. 이처럼 클래스는 어떤 대상의 유형을 정의하는 속성을 정리한 것이다.

 

컴포넌트: 비행기처럼 현실에 존재하는 복잡한 대상을 보면 작은 컴포넌트(Component)들이 모여 구성됐다는 것을 쉽게 알 수 있다. 비행기는 동체와 제어판, 랜딩기어, 엔진을 비롯한 수많은 요소로 구성된다. 절차형 프로그래밍에서 복잡한 작업을 작은 프로시저(Procedure) 단위로 쪼개는 것이 중요한 것처럼 OOP에서는 객체를 작은 컴포넌트 단위로 구분하는 사고방식이 중요하다.

 

프로퍼티: 객체는 프로퍼티(Property)로 구분한다. 앞에서 오렌지 클래스를 설명할 때 주황색을 띠고 독특한 맛을 내는 과일을 오렌지 클래스로 정의했다. 여기서 주항 색과 독특한 맛이란 두 가지 특징이 프로퍼티다.

 

동작: 동작(Behavior)은 객체가 하는 일 또는 그 객체로 할 수 있는 일을 표현한다. 오렌지의 경우 직접 하는 일은 별로

없지만 오렌지로 할 수 있는 일은 많다. 예로 '먹기'가 있다.

 

 

객체지향 디자인 원칙

솔리드 원칙

솔리드 원칙	설명
S	SRP(Single Responsibility Principle, 단일 책임성 원칙)
	컴포넌트마다 하나의 잘 정의된 책임을 가지며 관련 없는 기능을 합치지 않는다.
O	OCP(Open/Closed Principle, 개방/폐쇄 원칙)
	클래스는(상속을 통해) 확장에는 개방적이고(열려 있고), 수정에는 폐쇄적이어야(닫혀 있어야)한다.
L	LSP(Liskov Substitution Principle, 리스 코프 치환 원칙)
	어떤 객체의 자리를 그 객체의 서브타입 인스터스로 치환할 수 있어야 한다.
I	ISP(Interface Segregation Principle, 인터페이스 분리 원칙)
	인터페이스는 깔끔하고 간결해야 한다. 거대한 범용 인터페이스보다는 작지만 한 가지 책무라도 잘 정의된 인터페이스를 여러 개로 구성하는 것이 낫다.
D	DIP(Dependency Inversion Principle, 의존성 뒤집기/역전 원칙)
	인터페이스로 의존 관계를 역전시킨다.

 

출처 및 레퍼런스

Book: 전문가를 위한 C++ 17