절차지향(명령형) 프로그래밍
객체지향 프로그래밍(OOP)
함수형 프로그래밍(FP)
객체의 정의
객체의 다양한 정의
- 일반인 : 모든 물질
- 개발자 : 상태와 행위를 가진것으로, 비슷한 객체의 구조와 행동이 공통클래스로 선언 됨[Grady Booch, UML만듬]
- 펜 - 판서를하다(가장 보편적인 행위 - 행위를 추출해 내는거가 modeling임), 검은색 글씨가 써진다(상태)
- 행위를 변화시켰는데 상태가 변하네? - 캡슐화
- 상태(state) : field, 속성, 명사
- 행위(behavior) = 동사
- 메모리 : OOP는 컴퓨터를 표현 매체로 사용하는 움직임의 일부분
상속이 옛날에 중요했는데 요즘은 다형성(interface)이 훨씬 중요
객체 modeling
- 가장 보편적인 행위와 상태를 추출해서 프로그래밍 가능하도록 표현하는 작업과정
- 모델링시에 객체지향 엔지니어에 의한 주관적 성향이 포함 될 수 있음 (틀린건 아닌데, 좋은것도 아니다)
- 일반화 할 수 있도록 철저한 업무 분석(도메인 분석)이 필요
- 세무 회계 쪽 어플은 그쪽을 잘 아는사람이 유리
추상화 설계관점
- 주어진 어떤 일을 수행할 때, 필요하지 않은 복잡한 성질들은 무시하고, 커다란 개념 만을 이용하는 것
객체의 실체
다음 4개의 속성을 갖는 어떤 실체를 의미
- 유일성(identity)를 가지고 있어야함 (hashcode)
- 객체는 추상 데이터 타입(보통 class)를 가지고 있어야함
- 각각의 객체는 정확하게 하나의 클래스의 멤버(인스턴스)여야 함.
- 객체는 필드(속성)을 가질 수 있음
- 필드(속성)란 데이터를 저장하는 슬롯
- 같은 클래스에서 생성된 모든 객체는 동일한 필드를가짐
- 객체는 메세지를 가질 수 있음
- method(함수와 다름)를 호출하는 것
객체 모델링
- Domain Analysis
- Generalization
- Object Modeling
- Encapsulation
- Object OR Instance
- Abstraction
모델링 해보자
byte : -256 ~ 256?
short : 32000까지?
int : ~21억
long : ~900경?
float : 4바이트
double : 8바이트
ex 1 ) 농구
state(명사) - 시간, 점수,
behavior(동사) - 슛을소다, 패스를하다, 드리블하다, 리바운드하다
행위에 의해 상태가 변한다 (Encapsulation)
지금까지 UML을 만든거
농구 → class
state → field, property 원래 field로 해야하는데 kotlin에서는 property라 하자
behavior → method, fun(kotlin에서)
점수 : short (int는 너무큼)
시간 : float (double은 8바이트라 크다)
ball 모델링 해야함 → 상태(무게), 행위가 있다(튀어오르다)
ex 2) 계좌
state - 잔고, 이름, 전화번호
behavior - 이체하다(과제?), 출금하다, 입금하다
행위만 접근 할 수 있도록 - private
잔고 - private var balance float (int는 21억만 벌거냐? - 정하는것도 개발자 실력) , 초기값 할거면 - 0.0f
출금하다 - fun withdraw(money: float){ if(money ≤ balance) {this.balance..~~} } (행위를 통해 상태가 변한다)
객체지향 4대 특징
- 캡슐화
- 데이터를 보호하고 외부에서 직접 접근하지 못하도록 함으로써 클래스 내부의 구현 세부 사항을 숨기는 원칙
- 상속
- 기존 클래스를 재사용하여 새로운 클래스를 만들고, 코드의 중복을 줄이는 개념.
- 기존 클래스(부모)의 속성과 메서드를 물려받아 새로운 클래스(자식)를 생성.
- 다형성
- 하나의 객체나 메서드가 여러 가지 형태를 가질 수 있는 능력
- 추상화
- 구체적인 구현을 숨기고, 필요한 기능만 외부에 제공하는 것
상속보다는 association(has a)
has a 관계를 분리하는게 clean architecture
mvc문제? - view가 상태까지 가지고 있으면 안됨
바이트 코드 명세의 이해
밑의 그림을 잘 이해하자
모든게 class area에 전부 로딩됨
entry point가 stack frame(stack이니 위로쌓임)으로 들어감 (kotlin은 fun main)
thread 생성, 단점 간단히 (3년전부터 잘안다룸)
coroutine이 훨씬 중요
vm memory(런타임 시) 3가지만 기억하자 - class area, heap memory, stack frame
- class area[method area]
- 자바 클래스들이 로딩되는 영역
- stack frame
- method함수들이 실행되는 영역
- multi-thread 기반으로 실행됨
- heap
- 객체라고 불리는게 놓여져 있는 곳
- 모든 객체는 여기에 만들어짐
