개체지향 프로그래밍의 필요성

구조체의 한계

절차적 언어의 아쉬운 점

  1. 데이터의 비인간화
  2. 데이터가 많아지면 관리가 힘듬

구조체의 등장

  • 데이터를 그룹으로 묶어 새로운 데이터 형을 만드는 방법
  • 하나의 변수처럼 사용
struct Human //구조체의 선언
{
    int age;
    float height;
}

Human dave; //구조체 변수의선언
Human fioan

구조체의 한계

  1. 데이터와 동작이 분리되어 있음.
  2. 어떤 구조체가 어떤 함수란 연관 있는지 찾기 복잡함.

보완 : 파일 단위로 분리

하지만 언어자체에서 지원이 아님

보다 근본적인 문제

실세계에서 사람은 어떻게 생각하고 행동할까?

  1. 누구에게 말하고 있는가? : 실세계에서 누군가에게 이 말을 함.
  2. 미용사가 아이의 모든 정보를 알아야 하나? : 필요한 정보만 공개

사람은 세상을 물체(object)의 집합으로 인지.

일반적인 이야기 : 모든 것을 물체로 보진 않음 object를 프로그래밍에서는 객체 또는 개체라 번역. 물체는 상태를 가질뿐만 아니라 동작도 할 수 있음.

상태와 동작

  • 프로그래밍에서 변수는 상태를 저장
  • 동작 : 함수
  • 개체란 상태(변수 데이터) 외에 동작(함수)까지 포함

모든것이 개체는 아니다.

개체지향 프로그래밍

  • object oriented programming
  • 프로그래밍 패러다임 중 하나
  • 프로그램을 구성하는 기본 요소를 개체로 보려는 노력.
  • OOP에서 프로그램이란?
    • 상호작용하는 개체들의 집합
    • 절차적 프로그래밍은 실행할 명령어의 목록을 프로그램으로 봤음

절차적 프로그래밍은 매우 객관적

  • 기계어는 위에서 아래로 차례대로 실행됨
  • 어셈블리 명령어는 거의 모든 경우 기계어로 1:1 치환가능
  • C 언어로 작성한 코드 한 줄은 보통 어셈블리 명령어 몇 개로 치환 가능
  • 함수 호출은 특정 메모리 위치로 jmp해서 순서대로 명령어를 실행하는 것
  • 그 명령어 실행 결과에 따라 레지스터 또는 메모리에 저장된 데이터가 변경

어떤 프로그램이라도 최종적으로는 절차적으로 돔

  • OOP는 기계처럼이 아니라 사람처럼 생각하자는 운동
  • 주관적
  • 사회와 기술이 발전함에 따라 사람들이 사고방식도 변함

oop는 주관적

  • 70+년 역사 동안 다양한 학설 및 의견이 등장하고 사라짐
  • object에 대한 정의조차 다양했음
  • 오늘날에도 어떤 자료를 보고 배웠냐에 따라 정의가 달라짐

다수가 따르는 OOP 개념이 있음

  • JAVA C# C++등 주류 OOP언어들이 교통정리를 끝냄
  • 많은 사람들이 따르고있음

OOP 토론 시 피해야 할 사람

올바른 OOP가 아니야!

  • 특정 소수설의 관점을 지지하는 사람
  • 역사적 가치가 있는 주장도 있음
  • 특수한 상황에서 올바른 방법이기도함.
  • 일반적으로 해가 되기 쉬움
  • 남들이 신경 안 쓰는 내용을 안다고 자신이 똑독한 사람은 아님
  • 진실을 전파하는 유일한 방법 : 장점을 최대한 객관적으로 보여준다.

순수 OOP 언어가 아니야!

  • 순수 OOP 정의는 존재하지 않음.
  • 모두가 동의하는 최소한의 특성은 있음
  • 순수 OOP를 주장하는 사람들의 흔한 패턴

모든 프로그램은 OOP로 만들어야 해!

  • OOPO가 절차적 프로그래밍을 완전히 대체할 거라는 주장도 있었음
    • 새로운 기법이 처음 등장할 때 많이 보이는 잘못된 주장
    • 요즘에는 다른 패러다임이 OOP를 완전히 대체할 거란 주장도 종종보임
  • 역사적으로 사실이 아님이 증명됨
  • OOP가 주류고 한동안 이어질것

~한 ~가 이리 말했으니 너는 틀려!

  • 그릇된 권위에 호소
  • 용어 처음 주창한 사람에 따르면~
  • ~책에 따르면
  • 제대로 된 실무자 또는 학자라면 ‘과학적 사고방식’을 따름

이 방법만 따르면 문제가 해결돼!

  • 훌륭한 프로그래머는 해결하려는 문제에 적절한 도구를 사용

믿고 거르자

OBJECT

  1. 개체란 서로 연관 있는 상태와 동작을 가지고 있다.(캡슐화)
  2. 사람들은 기본적으로 세상을 개체들의 모음으로 본다.

oop의 4대 특성

7대 개념

  1. encapsulation
  2. inheritance
  3. polymorphism
  4. abstraction
  5. association
  6. composition
  7. aggregation

캡슐화

  • 데이터와 그 데이터에 작용하는 메서드를 하나로 묶음
  • 정보 숨기기 개체 안에 있는 데이터를 외부로부터 보호

상속

진화

  • 이미 존재하는 개체를 기반으로 확장된 개체(클래스)를 만드는 방법
  • 확장된 개체
    • 기존의 개체에 속한 데이터와 동작을 모두 물려 받음
    • 여기에 다른 데이터나 동작을 추가할 수 있음
  • 코드의 중복을 막음
  • 사람에게는 점진적 학습이 가장 효율적

다형성

같은 지시를 내렸는데 다른 종류의 개체가 동작을 달리하는 것.

  • 동일한 함수 시그내처 호출
  • 개체에 따라 달리 동작.

함수 구현이 실행될지는 실행 중에 결정됨 늦은 바인딩late binding이라 함

일반적인 함수 호출은 이른 바인딩early binding 컴파일중에 결정됨

다형성의 혜택을 받으려면 상속 관계가 필요

  • 부모 개체에서 함수 시그내처를 선언
  • 자식 개체에서 그 함수를 다르게 구현

-실용적인 용도: 다른 종류의 개체를 편하게 저장 및 처리 가능 bird cat dog등을 animal배열에 저장

  • subtype 다형성 다형성은 99%이것을 지칭

다른 다형성

  1. 애드혹ad-hoc 다형성
    • 함수 오버로딩, 연산자 오버로딩
    • 함수명은 같은데 매개변수 목록이 다름
  2. 매개변수 다형성
    • C#과 java의 제네릭
    • C++의 템플릿

허나 둘 다 일반적으로 다형성이라고 안 부름 OOP하고도 상관없음

데이터 추상화

  • 수학 : 일반화란 의미(반의어 : 구체화)

  • OOP : 개체 속에 있ㄴ느 실제 데이터나 함수 구현 방법에 종속되지 않겠단 뜻

  • 데이터 추상화 : 개체 사용 시 그 안에 정확히 어떤 데이터가 있는지 알 필요 없음, 개체 안에 잇는 데이터에 직접 접근 불가
    • 캡슐화는 데이터 추상화를 이루는 방법 중 하나
  • 추상화
    • 다형성을 통한 추상화
    • 추상 클래스(abstract class)나 인터페이스(interface)를 사용하는 추상화

연관

어떤 개체가 제공하는 기능을 다른 개체가 이용하는 관계 상속과 비교해서 설명

  • 상속은 자식 개체가 부모 개체의 모든 것을 내포하는 관계
  • 연관은 한 개체가 다른 개체를 참조하는 관계

  • 실세계에서 개체들이 상호작용하는 모습은 보통 연관과 비슷함

  • 세부적으로 다시 집합과 컴포지션으로 나누기도 함
    • 특히 UML이란 다이어그램을 그릴때
    • 이 셋을 구분하지 않고 다 합쳐서 컴포지션이라 하기도 함.

컴포지션

부품

집합과의 차이 : 부품 그 자체로는 존재 의의가 없음 조립품이 소멸할때 부품도 같이 소멸

집합

A대학에 등록한 학생들

역시 여러개체를 모아 다른 개체를 만들지만 별도로도 존재 가능