06/15 TIL (OOP 필요성)

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

 : 절차적 언어 아쉬운 점 : 데이터의 비인간화 (사람이 사람대로 사는 것이 아니라 몸1, 몸2 이런 식으로 나뉘게 된다.)

 : 절차적 언어 아쉬운 점 : 데이터가 많아질 때 관리가 힘들어짐 (비이상적 예외라던지)

 : 보완책 C에서는 구조체 (C언어 구조체는 데이터만 딱 들어있음)

 

 - 실세계 사람은 어떻게 생각하고 행동할까 (상태와 행동이라는 개념)

 : 대상이 동작을 수행하는 것

 : 대상이 굳이 알지 않아도 되는 정보는 알지 않아도 된다.

 : 대상은 필요한 정보만 알면 된다.

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

 : 물체는 상태를 가질 뿐만 아니라 동작도 할 수 있음

 : 상태 저장은 변수 & 동작은 함수

 : 어떠한 상태가 나한테 필요하냐, 어떠한 동작을 해야하나

 : but 모든 것이 개체는 아님 : 데이터가 업데이트만 하는 상황 (=덮어쓰기)

 

 - 개체지향 프로그래밍

 : OO (설계까지만) && OOP (프로그래밍)

 : Programming Paradigm 중 하나다

 : 상호작용하는 개체들의 집합

 : 절차적 프로그래밍 => 기계어는 위에서 아래로 차례대로 실행 => 최종적으로는 절차적 프로그래밍과 같이 돔

 

 - OOP는 주관적이다.

 : 개체에 대한 정의조차 바뀐 주관적 패러다임이다.

 : 주관적이기 떄문에 다수, 소수설이 있음.

 : 충돌 시 의견 나눌 때 : 장점을 최대한 객관적으로 보여주어야 한다.

 * 꿀팁 : 올바른, 순수, 모든, 누가 뭐라고 했으니, 이 방법만 따르면 -> 어떠한 것은 단일화 될 수 없음

 

- OOP 특성

 : 보통은 4가지 특성이 있다함

 : 문헌에 따라 3대 특성 or 7대 개념이라 하기도 함

 3대 특성 : 캡슐화(encapsulation) && 상속(inheritance) && 다형성(polymorphism)

 + 1 특성 : (데이터) 추상화 ((data) abstraction)

 + 3대 특성 : 연관(association) && 컴포지션(composition) && 집합(aggregation)

 

 - 캡슐화

 : 데이터와 그 데이터에 작용하는 메서드를 하나로 묶음

 : 정보 숨기기 개체 안에 있는 데이터를 외부로부터 보호 (은닉화: data hiding)

 

 - 상속

 : 이미 존재하는 개체를 기반으로 확장된 개체를 만드는 방법 (진화의 개념)

 : 코드 중복을 막음, 사람에게 점진적 학습이 가장 효율적이기에 이해도 가깝다.

 

 - 다형성

 : 같은 지시를 내려도 다른 종류의 개체가 동작을 달리 하는 것

 : 같은 지시 = 함수 시그내쳐 호출

 : 기존의 절차적 언어라면 if가 필요했음 a면 이거 b면 이거 c면 이거

 : 늦은 바인딩이라고 함 (이른 바인딩: 함수 호출 : 컴파일 단계 의존성)

 : 다형성 혜택을 받으려면 상속 관계 필요함.

 - 다른 종류 다형성

 : 애드혹 다형성(ad-hoc) : 연산자 오버로딩, 함수 오버로딩 (ad-hoc: 기다리지 않고 딱 상황에 닥치면 한다)

 : 매개변수 다형성 : Generic  

 

 - (데이터) 추상화

 : 추상화란 구체적인 것의 공통적인 것을 합쳐서 일반화 하는 것 (반댓말 : 구체화)

 : 개체 안에 정확히 어떤 데이터가 있는지 알 필요 없음

 : 다형성을 통한 추상화 (abstract class && interface)

 

 - 연관

 : 어떤 개체가 제공하는 기능을 다른 개체가 이용

 : 실세계 개체들은 연관과 좀 더 비슷

 : 연관, (집합/컴포지션) -> UML 연관, (집합+컴포지션 -> 컴포지션이라 불러버림)

 

 - 컴포지션

 : 부품 그 자체로는 의미가 없음

 

 - 집합

 : 부품 그 자체로도 존재 가능 의미가 있음