1.
객체지향 프로그래밍
4팀 - 박도일 이세나 최선우 노우진 김재성 용준헌

2.
- 목차
▪ 객체지향 프로그래밍이란?
▪ 객체지향 프로그래밍의 주요 개념
▪ 객체지향적 설계

3.
- 객체지향 프로그래밍이란?
절차 지향 프로그래밍의 한계
1. 데이터와 데이터를 다루는
함수가 분리.
2. 각 함수의 식별자가 항상
달라야 함.
3. 프로그램 확장이
불편함.
=> 유지 보수가 불편함.

4.
- 객체지향 프로그래밍이란?
- 객체중심으로 프로그래밍
- 객체 : 데이터 영역에 존재. 변수
등의 집합체
- 메소드 : 함수
- 필드 : 데이터

5.
- 객체지향 프로그래밍의 주요 개념
1. 캡슐화
2. 상속
3. 추상화
4. 다형성

6.
- 객체지향 프로그래밍의 주요 개념
1. 캡슐화
- 데이터와 데이터를 다루는 함수를 같이 작성.
- 접근 지정자를 이용, 데이터를 은닉하고, 필요한 만큼만 외부
로 공개함.
- 데이터를 보호하고 오용을 방지함.

7.
- 객체지향 프로그래밍의 주요 개념
* 접근 지정자.
- 어떤 객체를 외부에 공개할 것인지 결정.
- public : 공개 멤버, 클래스 외부에서도
접근 가능
- protected : 자기 클래스 내부 혹은 상속
받은 자식 클래스에서 접근 가능
- private : 비공개 멤버, 외부에서 접근 불
가능

8.
- 객체지향 프로그래밍의 주요 개념
2. 상속
- 코드를 물려받아 재사용.
- 기존 정의된 클래스의 모든
멤버 변수 상속.
- 새로운 하위 클래스 작성.

9.
- 객체지향 프로그래밍의 주요 개념
3. 추상화
- 구현 세부 사항을 숨기는 *인터페이스 정의
* 인터페이스 : 서로 다른 부분이 만나고 소통하거나 서로에
게 영향을 미치는 영역.
- 구현 세부 사항에 변화가 생겨도 사용하는 방식에는 달라지는
것이 없기 때문에 확장성도 가지게 됨.
- 추상화를 잘할수록 데이터를 다루기 쉬워짐.

10.
- 객체지향 프로그래밍의 주요 개념
4. 다형성
- 동일 인터페이스 내에서 다른 동작을 하는 것.
- 가상 함수를 사용하여 같은 이름의 메소드가 서로 다른 동작을 하게
됨.
- 가상함수는 virtual 키워드를 사용하여 선언.

11.
- 객체지향 프로그래밍의 주요 개념
* 가상함수
- 다형성을 지원하기 위한 기능
- 오버라이딩을 통해 파생 클래스에서
재정의하는 함수
- 오버라이딩 : 가상 함수의 내용을 재
정의하는 것.
- 부모 클래스 타입을 가리키는 포인터
나 레퍼런스로 업캐스팅 해야함.
- 가상함수 테이블과 가상함수 포인터
로 작동함.

12.
- 객체지향적 설계
- 객체지향 프로그래밍 언어로
절차지향적 설계 -> 잘못된 설계.
- 어떤 기능이 필요한 지 먼저
생각.
- 이 후, 기능 구현을 위해 어떤
데이터가 필요한 지 생각.
- 객체지향적 설계에는 보통
책임 주도 설계를 많이 사용함.

13.
- 객체지향적 설계
- 책임 주도 설계
1. 협력
2. 객체
3. 책임
4. 메시지
5. SOLID 원칙

14.
- 객체지향적 설계
1. 협력 : 요청과 응답으로 이루어 짐.
• 요청
• 상대방이 문제를 해결 할 수 있을 것이라고 생각하고 요청하게 됨.
• 협력의 성공은 특정 역할을 맡은 각 개인이 얼마나 요청을 이행할 수
있는가에 달려있음.

15.
- 객체지향적 설계
2. 객체 : 상태와 행동을 함께 지닌 실체
• 좋은 객체가 갖춰야 할 요소
1. 객체는 충분히 협력적이어야 함.
2. 객체는 충분히 자율적이어야 한다.

16.
- 객체지향적 설계
1. 객체는 충분히 협력적이어야 함.
- 다른 객체의 요청에 잘 응답하고, 다른 객
체에 협력을 요청 해야 함.
2. 객체는 충분히 자율적이어야 함.
- 요청에 응하는 여부부터 방식까지 객체
스스로 결정.
- 객체 내부와 외부를 명확하게 구분.
- 객체의 외부에서는 접근이 허락된 수단을
통해서만 의사소통을 하게 된다.

17.
- 객체지향적 설계
3. 책임 (역할)
• 요청을 처리하기 위해 객체가 수행하는 행동.
• 기능을 수행할 수 있게 여러 책임으로 나누고, 각 개체에 부여하여
협력하게 만들어야 한다.
• 책임은 객체가 어떻게가 아니라 무엇을 해야 하는가를 설명
해야함.
• 과도하게 구체적 - 수행 방법에 제한
• 과도하게 추상적 -의도를 명확하게 표현불가

18.
- 객체지향적 설계
4. 메시지
• 객체지향에서 도움을 요청하는 유일한 방법
• 협력은 메시지를 주고 받는 송신자와 수신자 사이의 관계로 구성.
• 메시지를 처리하는 방법을 메소드라고 한다.
• 메시지와 요청을 처리하기 위한 메소드를 분리하는 것이 객체의
자율성을 높이는 핵심이다.

19.
- 객체지향적 설계
5. SOLID
• 클린 아키텍처에서 소개된 객체지향 설계의 바탕이 되는 5가지 원칙
• 단일 책임 원칙 (Single Responsibility Principle)
• 개방 - 폐쇄 원칙 (Open - Closed Principle)
• 리스코프 치환 원칙 (Liskov Substitution Principle)
• 인터페이스 분리 원칙 (Interface Segregation Principle)
• 의존성 역전 원칙 (Dependency Inversion Principle)

20.
- 객체지향적 설계
1. 단일 책임 원칙 (Single Responsibility Principle)
• 각 소프트웨어 모듈은 변경의 이유가 하나여야함.

21.
- 객체지향적 설계
2. 개방 - 폐쇄 원칙 (Open - Closed Principle)
•객체는 확장에는 열려 있어야하고, 변경에는 닫혀 있어야함.
•수정보다는 새로운 코드를 추가하는 방식으로 변경하도록 설계되어야함.
•데이터가 아닌 메소드를 다뤄서 변경해야함.

22.
- 객체지향적 설계
3. 리스코프 치환 원칙 (Liskov Substitution Principle)
•프로그램 P에서T타입의 객체 자리에 S타입의 객체로 모두 변경 해도,
P의 행위가 변하지 않는다면 S는T의 하위 타입이다.

23.
- 객체지향적 설계
4. 인터페이스 분리 원칙 (Interface Segregation Principle)
• 결합도 수준을 메시지 수준으로 낮춘 협력 관계를 구축 해야 함.

24.
- 객체지향적 설계
5. 의존성 역전 원칙 (Dependency Inversion Principle)
• 고수준 정책 구현 코드는 저수준 세부사항 구현 코드에
절대로 의존해서는 안됨.
• 따라서, 다형성을 적극적으로 사용해야한다.