[기술 질문]#9_객체 지향 프로그래밍(OOP)

 

[기술 질문] #9_객체 지향 프로그래밍(OOP)

 

객체 지향 프로그래밍에 대해 알아보겠습니다.

 

---

 

Overview

 

1. 개념
2. 네 가지 특성
3. 다섯 가지 원칙

 

#1. 개념

1. OOP??

• 객체 지향 프로그래밍은 컴퓨터 프로그램을 명령어의 목록으로 보는 절차 지향적 시각에서 벗어나, 실세계에 존재하고 인지하는 "객체"를 소프트웨어 세계에서 표현하기 위해 객체의 핵심적인 개념과 기능만을 추출하는 추상화를 통해 모델링하려는 프로그래밍 패러다임을 의미합니다.

 

#2. 네 가지 특성

1. 캡슐화(Encapsulation)?

• OOP의 캡슐화란 데이터와 코드의 형태를 외부로부터 은닉하고, 데이터의 구조와 역햘, 그리고 기능을 하나의 캡슐 형태로 만드는 방법입니다.
• 예를 들면,  클래스의 private 접근 제어자 활용과 Getter&Setter 함수 활용을 통해 캡슐화가 가능합니다. 

 

2. 추상화(Abstraction)?

• OOP의 추상화란 객체의 속성과 기능들을 추출해 한데 묶어놓는 작업을 의미합니다.
• 클래스를 선언하는 것과 마찬가지로, 서로 다른 클래스들의 공통적인 특징등을 한데 묶어 해당 클래스들의 부모 클래스를 선언하는 작업 또한 추상화 작업입니다.

 

3. 상속(Inheritance)?

• OOP의 상속은 상위 개념 혹은 클래스의 속성과 기능들을 하위 개념의 클래스가 물려받는 것을 의미합니다.

 

4. 다형성(Ploymorphism)?

• 프로그래밍 언어의 다형성이란 프로그램 언어의 각 요소들(상수, 변수, 오브젝트, 메서드 등)이 다양한 자료형에 속하는 것이 허가되는 성질을 뜻합니다.
• C++의 "오버라이딩" 혹은 "오버로딩"의 경우 부모 클래스의 멤버 함수를 자식 클래스에서 동일한 이름으로 재정의 할 수 있습니다. 이때, 해당 메서드는 하나의 자료형에 귀속되는 것이 아니라, 다른 자료형에 속하는 것이 허가되는 것이죠!
• 대표적인 예로 오버로딩과 오버라이딩이 있습니다!

 

[Basic C++] #6_오버라이딩과 오버로딩의 차이점

 

#3. 다섯 가지 원칙

1. SRP(Single Responsibility Principle), 단일 책임 원칙?

• 작성된 클래스는 오직 하나의 기능만 책임지며, 해당 클래스가 제공하는 모든 서비스는 그 하나의 책임을 수행하는데 집중합니다.
• 결과적으로, 코드 수정 시 어떤 클래스의 변경이 다른 클래스의 변경으로 옮겨가는 연쇄 작용으로부터 방지합니다.
• SRP는 코드 "가독성"과 "유지보수성" 향상의 장점이 있습니다.

 

2. OCP(Open-Closed Principle), 개방-폐쇄 원칙?

• Bertrand Meyer 박사는 "객체지향 소프트웨어 설계"에서 소프트웨어의 구성요소(컴포넌트, 클래스, 모듈, 함수 등)는 확장에 열려있고, 변경에는 닫혀있어야 한다고 설명합니다.
• 이때, 중요한 OOP의 성질은 물론 추상화와 다형성이겠죠.
• 추상화란 다른 모든 종류의 객체로부터 식별될 수 있는 객체의 본질적인 특징입니다.

 

3. LSP(Liskov Substitution Principle), 리스코브 치환 원칙?

• LSP란, "서브 타입은 언제나 기반 타입으로 교체될 수 있어야 한다"입니다. 즉 LSP를 충족시키기 위해서 서브 타입은 기반 타입과 약속한 규약 혹은 인터페이스를 준수해야 합니다.
• LSP를 총족시키기 위한 방법은 상위 클래스 활용입니다. 선언은 기반 클래스에(상위), 그리고 생성은 구체 클래스로 대입하도록 합니다.
• 결과적으로, LSP는 OCP를 구성하는 주요 원칙입니다. LSP는 하위 클래스의 규약 준수와 함께 단단한 상속 구조를 형성해  OCP를 통한 코드의 다형성과 확장성 제공의 기반이 됩니다!

 

4. ISP(Interface Segregation Principle), 인터페이스 분리 원칙?

• ISP는 어떤 클래스가 자신이 사용하지 않는 인터페이스에 대한 구현을 금지합니다. 다시 말해, 어떤 클래스는 최소한의 인터페이스만을 사용해야 합니다.
• 하위 클래스의 최소한의 인터페이스 활용을 위해 먼저 하나의 일반적인 인터페이스를 여러 개의 구체적인 인터페이스로 대체해야 합니다. 인터페이스가 너무 일반적일 경우, 하위 클래스는 손해를 감수하고(?) 해당 인터페이스를 사용해야 하기 때문이죠.
• ISP는 인터페이스의 단일 책임을 강조합니다.

 

4. DIP(Dependency Inversion Principle), 의존성 역전의 원칙? 

• 의존 관계의 역전이란 하위 레벨 모듈의 변경이 상위 레벨 모듈의 변경을 요구하는 위계 관계를 끊는 것을 의미합니다.
• 상위 레벨 모듈과 하위 레벨 모듈은 추상을 매개로 메시지를 주고받음으로써 의존성을 낮춥니다.
• DIP의 3가지 구성 요소는 "IOC(Inversion Of Control)", "훅 메서드",  그리고 "확장성"입니다.
• Callee는 Caller가 확장할 훅 메서드 인터페이스를 정의합니다. Caller는 훅 메서드를 구현합니다.
• Caller는 Callee에 자신을 등록하고, Callee는 Caller에게 정보를 전달할 적당한 시점에 Caller의 훅 메서드를 호출하죠.
• 이를 통해, 호출 관계가 역전되는 IOC 시점이 됩니다.
• DIP는 컴포넌트 간의 비동기적 커뮤니케이션, 그리고 커뮤니케이션 방식의 단순화를 위해 활용됩니다.