.

1. 객체 지향 프로
그래밍

2. 절차 지향 프로그래밍의 불편함을 해소하기 위해 나온 새로운 프로그래밍 패러
다임
- 객체지향의 특징
객체를 중심으로 하는 프로그래밍방법으로 누가 어떤 일을 하는지에 핵심을 둔다.
- 객체지향언어를 사용하는 이유
절차지향언어의 한계를 극복하기 위해서
객체지향 프로그래밍

3. 객체지향 프로그래밍
절차지향의 한계
1. 데이터와 데이터를 다루는 함수가 분리되어 있다.
프로그램을 만들 때 해당 타입을 다루는 함수를 쓸 때마다 첫 인자로 주소값을 불러와야 하기에
쓸데없이 길어지고 함수 내 포인터를 사용해 데이터를 다룰 필요가 있다.
1. 함수의 이름이 항상 달라야 한다.
C에선 함수의 이름이 *전역공간에 저장되기 때문이다.
1. 프로그래밍 확장성이 떨어진다.
함수를 쓸 때마다 무슨 함수인지 명확하게 적어야 했고 프로그램 수정사항이 생길때 바꿀
점이 많았다.
*전역 공간 :프로그램의 어디에서나 접근할 수 있는 공간.

4. 객체지향 프로그래밍
객체지향의 역사
- 1968년 절차지향언어는 소프트웨어의 유지보수와, 재사용이 어렵다는 문제가 제기되었고 이에
대한 해결 방안으로 객체지향 언어가 제시되었다.(software Crisis)
- 1960년대 말 최초로 객체지향언어인 ‘시뮬라67’이 나왔다
하지만, 당시에는 전혀 주목받지 못했다.
- 1970년대 말 두번째 객체지향 언어인 ‘스몰토크’가 나왔고 아이디어는 ‘시뮬라67’에서 얻어왔으
며 현재까지도 인정받고 있다.
- 1980년대 초 나온 객체 지향 언어는 ‘에이다’인데 가장 큰 특징으로 예외처리를 도입했다
하지만, 큰 단점이 있었는데 에이다는 상속의 개념을 반영하지 않았다.
- 1990년대 초 프로그래밍 언어가 많은 지원을 받으며 기본적으로 ‘스몰토크’와 ‘에이다’의 틀을 따
르며 둘의 문제점을 해결하는 방식으로 발전했다.

5. ● 데이터와 데이터를 다루는 함수를 같이 작성하는 것
| 클래스라는 일종의 틀에서 접근지정자를 통해 그 클래스 외부에서
그 안의 멤버 변수와 메소드에 쉽게 접근이 가능하다.
4가지 개념
1.캡슐화(Encapsulation)

6. ● 데이터와 데이터를 다루는 함수를 같이 작성하는 것
| 클래스라는 일종의 틀에서 접근지정자를 통해 그 클래스 외부에서
그 안의 멤버 변수와 메소드에 쉽게 접근이 가능하다.
4가지 개념
1.캡슐화(Encapsulation)
● 접근제한자 (public, private)를 사용하기 때문에 외부로부터 객체에 포함된 정
보의 손상과 오용을 막을 수 있다.
● 객체 내부의 조작 방법이 바뀌어도 사용방법은 바뀌지 않는다.
● 데이터가 바뀌어도 다른 객체에 영향을 주지 않아 독립성이 유지된다.

7. ● 자식 클래스가 부모클래스의 코드를 물려받는 것(코드 재사용)
| 상속은 반복된 코드의 중복을 줄이고 유지보수가 편리하다.
| 객체의 다형성을 구현 할 수 있게 해준다.
4가지 개념
2. 상속(Inheritance)

8. 4가지 개념
3. 추상화(Abstraction)
● 구현 세부 정보를 숨기는 일반적인 인터페이스
- 객체들의 공통 속성과 행위를 추출하여 인터페이스를 이용하는 것 같이
데이터를 다루기 쉬우며 더 빠르고 편리하게 안전하게 작성 할 수 있음
- 세부사항에 변화가 생기게 되더라도 확장성 또한 가지게 됨
● 데이터, 수행과정이 비슷한 개념으로 묶어 정의, 선언
하는 것

9. 4가지 개념
4.다형성(Polymorphism)
● 하나의 변수 또는 함수가 상황에 따라 여러가지 형태를 가지고 여러
의미로 해석될 수 있는 것
- 프로그램 언어의 각 요소들(상수, 변수, 식, 오브젝트, 함수, 메소드 등)이 다양한 자료형
(type)에 속하는 것이 허가되는 성질, 다형성 구현하는 대표적인것으로는 오버로딩
(Overloading)과 오버라이딩(Overriding)이 있다.

10. - 책임 주도 설계(Responsibility-driven Design)
|객체 지향적 설계를 하는 테크닉 중 하나
- 주요 요점
|협력: 요청과 응답
|객체: 상태와 행동
|책임: 요청에 대한 행동
|메시지: 요청에 대한 방식
객체지향적 설계
-책임 주도 설계-

11. - 협력
|도움을 요청하는 것 + 그 사람의 응답
|요청받은 사람은 해당 요청을 성실히 이행할 책임이 있다
바리스타가 주문에 맞는 커피를 주어야 하는 책임
|커다란 기능을 작은 여러 책임으로 나누고
|적절한 역할의 객체에게 부여하여 이행하게 한다
>> 적절한 객체에게 적절한 책임을 부여하는 것
객체지향적 설계
-책임 주도 설계-

12. - 객체
|상태와 행동을 함께 지닌 실체
● 좋은 객체란?
| 충분히 협력적이어야 한다
요청 잘 처리 + 적극적인 요청
| 충분히 자율적이어야 한다
요청을 스스로 판단하여 결정(내부 접근에 대한 요청에 대한 처리 등)
객체의 외부와 내부를 명확하게 구분하는 것으로부터 나옴
EX. 바리스타는 원두를 요청하여 받은 원두로 커피를 잘 만들어야 하고,
손님이 자신의 원두를 함부로 손 댈 수 없도록, 자신을 통해서만 접근할 수 있도록 해야 한다
객체지향적 설계
-책임 주도 설계-

13. - 책임
|요청을 처리하기 위해 객체가 수행하는 행동
● 객체 지향적으로 설계할 때는…
|기능을 명세 하고
게임을 만드는 게임 회사
|그 기능을 수행하기 위한 협력 관계를 구축하고
직원 복지를 위한 카페 < > 카페가 원두를 살 수 있는 돈을 버는 직원들
|각 객체에게 책임을 부여하여 협력하게 해야한다
직원들의 주문을 받아 커피를 만들어 제공하는 바리스타
객체지향적 설계
-책임 주도 설계-

14. ● 객체에게 책임을 부여하는 방법
| “어떻게”가 아닌 “무엇”을 설명
Ex. 직원이 요청하는 커피를 제공한다
|해당 설명은 너무 구체적이어도, 너무 추상적이어도 안된다
너무 구체적: 샷과 삼다수를 얼음 5개가 들어있는 컵에 담아 6.5C가 되도록 주세요
너무 추상적: 주세요
딱 알맞음: 아이스 아메리카노 주세요
객체지향적 설계
-책임 주도 설계-

15. - 메시지
|객체 지향 세계에서의 의사소통 수단
객체 지향에서 협력은 메시지를 전송하는 객체(송신자) 와
메시지를 수신하는 객체(수신자) 사이의 관계로 구성된다
● 메소드
|수신된 메시지를 처리하는 방법, 함수로 구현
|실행 시간에 메소드를 선택
>> 외부의 요청과 이 요청을 처리하는 방법을 분리하는 것이
객체의 자율성을 높이는 핵심 메커니즘(추상화)
객체지향적 설계
-책임 주도 설계-

16. SOLID원칙
SOLID 원칙은 클린 아키텍처에서 소개된 설계의 바탕이되는 5가지 원칙을 말한다.
5가지 원칙
● 단일 책임 원칙(Single Responsibility Principle)
● 개방-폐쇄 법칙(Open-Closed Principle)
● 리스코프 치환 원칙(liskov Substitution Principle)
● 인터페이스 분리 원칙(Interface Segregation Principle)
● 의존성 역전 원칙(Dependency Inversion Principle)
클린 아키텍쳐: 안정된 소프트웨어 아키텍처란 변동성이 큰 구현체에 의존하는 일은 지양하고, 안정된 추상 인터페이스를 선
호하는 아키텍처라는 뜻

17. SOLID원칙
단일 책임 원칙(Single Responsibility Principle)
|각 객체마다 단 하나의 책임이 있어야 한다
|클래스의 역할과 책임을 너무 많이 주지 말자
|관련된 책임만 주자

18. SOLID원칙
개방-폐쇄 법칙(Open-Closed Principle)
|객체는 확장에서는 열려 있어야 한다
변경에서는 닫혀있어야 한다
| 객체를 다룰때는 메소드로만 다룰수 있어야함
| 메소드만 변경해도 전체적인 흐름이 바뀌지 않는다
| 객체지향의 4개념중 캡슐화랑 연관이 있음

19. SOLID원칙
리스코프 치환 원칙(liskov Substitution Principle)
|하위 클래스의 인스턴스는 상위형 객체 참조 변수에 대입해 상위 클래스의
인스턴스 역할을 하는데 문제가 없어야 한다.
논리적 흠이 없어야함.
딸 is a 아버지(X)
포유류 is a 동물(O)
리스코프 치환 원칙 위배됨.
|객체지향의 4개념중 상속이랑 연관이 있음.

20. SOLID원칙
인터페이스 분리 원칙(Interface Segregation Principle)
|필요한 인터페이스만을 분리해 의존하게 설계하라는 원칙이다.
설계를 유연하고 확장성이 있고 재사용 가능하게 만들자.
결합도를 Message 수준으로 낮추자.
|상위클래스가 풍성할 수록 캐스팅
이 적게 일어나서 소스코드가
깔끔해진다. 때문에 상위클래스가
풍성할 수 록 좋다.

21. SOLID원칙
의존성 역전 원칙(Dependency Inversion Principle)
|고수준 정책을 구현하는 코드는 저수준 세부사항을 구현하는
코드에 절대로 의존해서는 안되며,세부사항이 정책에
의존해야 한다는 원칙.
|하위클래스나 구체클래스가 아닌 추상적인것에 의존하자.
|객체지향 프로그래밍 4개념중 다형성이랑 연관되어있음.

22. 프로그래밍 패러다임
● 프로그래밍 패러다임란?
| 어떻게 하면 그 언어가 가진 목적에 부합하게 사용할수 있는
지, 어떻게 하면 해당언어처럼 사고하는지와 관련된 것이다
● 멀티 패러다임 언어란?
| 프로그래밍 언어별로 지원하는 프로그래밍 패러다임이 다
르다
| 하지만 최근 대부분의 프로그래밍 언어는 여러 개의 패러다
임을 갖는다
| 이를 [멀티 패러다임 언어] 라고 부른다

23. 프로그래밍 패러다임
● 프로그래밍 패러다임
○ 명령형 프로그래밍
■ 절차적 프로그래밍
● 코드를 순차적으로 실행하는 방식이며, 변
수와 함수가 분리되어 작성한다
■ 구조적 프로그래밍
■ 객체지향 프로그래밍
○ 선언형 프로그래밍
■ 함수형 프로그래밍
■ 논리 프로그래밍
프로그램 패러다임
명령형 프로그래밍 선언형 프로그래밍
절차적 프로그래밍 객체 지향 프로그래밍
구조적 프로그래밍
함수형 프로그래밍 논리 프로그래밍

24. 프로그래밍 패러다임
● 프로그래밍 패러다임
○ 명령형 프로그래밍
■ 절차적 프로그래밍
■ 구조적 프로그래밍
● GOTO문의 결점을 제거하고자 하는데에
서 출발한 프로그래밍 기법
■ 객체지향 프로그래밍
○ 선언형 프로그래밍
■ 함수형 프로그래밍
■ 논리 프로그래밍
프로그램 패러다임
명령형 프로그래밍 선언형 프로그래밍
절차적 프로그래밍 객체 지향 프로그래밍
구조적 프로그래밍
함수형 프로그래밍 논리 프로그래밍

25. 프로그래밍 패러다임
● 프로그래밍 패러다임
○ 명령형 프로그래밍
■ 절차적 프로그래밍
■ 구조적 프로그래밍
■ 객체지향 프로그래밍
● 모든 데이터를 객체로 취급하며, 객체가
내부의 자료형과 함수로 구성된 프로그래
밍 구조를 지니고 있다
○ 선언형 프로그래밍
■ 함수형 프로그래밍
■ 논리 프로그래밍
프로그램 패러다임
명령형 프로그래밍 선언형 프로그래밍
절차적 프로그래밍 객체 지향 프로그래밍
구조적 프로그래밍
함수형 프로그래밍 논리 프로그래밍

26. 프로그래밍 패러다임
● 프로그래밍 패러다임
○ 명령형 프로그래밍
■ 절차적 프로그래밍
■ 구조적 프로그래밍
■ 객체지향 프로그래밍
○ 선언형 프로그래밍
■ 함수형 프로그래밍
● 순수 함수를 사용하는 방식
■ 논리 프로그래밍
프로그램 패러다임
명령형 프로그래밍 선언형 프로그래밍
절차적 프로그래밍 객체 지향 프로그래밍
구조적 프로그래밍
함수형 프로그래밍 논리 프로그래밍

27. 프로그래밍 패러다임
● 프로그래밍 패러다임
○ 명령형 프로그래밍
■ 절차적 프로그래밍
■ 구조적 프로그래밍
■ 객체지향 프로그래밍
○ 선언형 프로그래밍
■ 함수형 프로그래밍
■ 논리 프로그래밍
● 논리 문장을 이용하여 프로그램을 표현하
고 계산을 수행하는 개념
프로그램 패러다임
명령형 프로그래밍 선언형 프로그래밍
절차적 프로그래밍 객체 지향 프로그래밍
구조적 프로그래밍
함수형 프로그래밍 논리 프로그래밍

28. 명령형 프로그래밍 VS 선언형 프로그래밍
● 명령형 프로그래밍
○ 상태(변수)와 제어 흐름(함수)이 존재 하며, 상태를
필요에 따라 생성하고 정의하고 변경한다
○ HOW 어떻게 할것인가에 가깝다
○ 예시) C,C++,JAVA,JavaScript, Python, PHP
상태(변수)
제어흐름(함수)

29. 명령형 프로그래밍 VS 선언형 프로그래밍
● 선언형 프로그래밍
○ WHAT 무엇을 할것인가에 가깝다
○ 상태(변수)와 제어 흐림(메서드)이 존재하지 않는
다
○ 예시) HTML, SQL, XML , HASKELL

30. 감사합니다!