본문 바로가기

Archive

[코드스피츠 78] ES6+함수와 OOP

반응형

✔️코드스피츠 78 - ES6+함수와 OOP 1회차

 

*Sub Routine Flow

메인 플로우가 아니라 서브루틴을 중심으로 보고 함수가 아니라 루틴의 관점에서 본다. 

 

-ES6에서는 function을 절대 쓰지 않는다. 왜? Class의 method에 정의하기 때문

this(function)는 의미가 없어진다.

-Arrow Function 사용

-method는 class 구문으로 대체

 

*value vs reference

서브루틴에서 return 하는 게 ref 값이면 메인 플로우 안에 있는 원본 데이터를 변경시킬 가능성이 있다.

따라서, 되도록 서브루틴의 리턴 값은

1. readonly로 반환한다. 

2. 또는 새 객체로 만들어 반환한다. 

 

*Structured Design(구조적 설계) by 래리 콘스탄틴

- 우리는 낮은 결합도(coupling) & 높은 응집도(Cohesion)를 추구해야 한다!

 

>> Coupling

Contents (-)

 -  A클래스 속성 v가 변경되면 즉시 B클래스가 깨지는 경우

Common (전역 객체 사용) (-)

 - Common 클래스 변경 시 즉시 A, B클래스가 깨짐

External (-)

 - A, B클래스는 외부의 정의에 의존함. 멤버의 json 구조가 변경되면 깨짐

Control (factory pattern) (-)

 - A클래스 내부의 변화는 B클래스의 오작동을 유발

Stamp - 유사 약 결합 (-)

 - A와 B는 ref로 통신함

ref에 의한 모든 문제가 발생할 수 있음

Data (+)

 - A와 B는 value로 통신함

모든 결합 문제에서는 자유로워짐

 

 >> Cohesion

Coincidental(-)

아무런 관계가 없음. 다양한 이유로 수정됨

Logical(/)

사람이 인지할 수 있는 논리적 집합. 언제나 일부만 사용됨

Temporal(/)

시점을 기준으로 관계없는 로직을 묶음. 순서가 실행을 결정. 역할에 맞는 함수에게 위임해야 함

Procedural(/)

외부에 반복되는 흐름을 대체하는 경우 순서 정책 변화에 대응 불가

Communicational(/)

 하나의 구조에 대해 다양한 작업이 모여있음

Sequential

실행 순서가 밀접하게 관계되며 같은 자료를 공유하거나 출력 결과가 연계됨

Functional(+)

역할 모델에 충실하게 단일한 기능이 의존성 없이 생성된 경우 —> 우리의 달성 목표!

 

 

✔️코드스피츠 78 - ES6+함수와 OOP 2회차

 

*Spread Reference

*Sub Routine Chain (꼬리물기 최적화)

 - call stack : 각 서브루틴의 메모리는 데이터를 유지하고 있다. (execution context)

 - 즉, return point를 가지고 있다.

 

*Tail Recursion

 - 제어문은 제어문을 통해서 Stack Clear 기능 (ex. for문)

 - 언어 수준에서만 지원 가능

 - Safari 지원. Chrome 미지원.

 - 모든 연산자는 스택 메모리를 유발하여 꼬리물기 최적화를 방해한다.

 - JS에서 꼬리물기 최적화를 지원해주는 기능 : 삼항 연산자,  OR 연산자, AND 연산자

 —> Tail Recursion To Loop

 

*Closure

 - Global > Main Flow > Routine

 - Static State

 - Runtime State : routine 생성 

routine에서 접근하는 Main flow(scope)의 변수는 free variables(자유 변수)이다.

Routine 안에서 자유 변수를 다루어서 자유 변수가 변하지 못하게끔 갇히게 된다.

Free variables close —> “closure”

 

*Shadowing

 - 상위 변수명들과 현재 루틴의 변수명이 겹치면 가장 가까운 변수를 closure로 사용한다.

 - Nested Closure(중첩된 클로저)에서 외부 변수를 보호하는 유일한 방법

 - 권한과 보호의 문제

 

*Co Routine

  - 서브루틴에서 “yield” 사용

  - suspesion(일시정지) 발생

  - 우리가 짠 코드의 이해도가 상승

  - 재귀 함수 제어 가능

  - yield 지나고 난 뒤 coroutine.next() 형태로 다음 루틴 접근

 

 

✔️코드스피츠 78 - ES6+함수와 OOP 3회차

*HTML Parser

코드위주 강의... 어려워서 스킵함

 

 

코드스피츠 78 - ES6+함수와 OOP 4회차

 

*대화형 프로그래밍

이벤트에 대한 반응형 프로그래밍 같은것

이벤트 프로그래밍

다이얼로그 프로그래밍

일관성을 유지하는 데 필요

 

*테트리스

실시간 프로그래밍

모델링

 : 도메인 분석 / 반드시 구분기억해야하는 특징이 무엇인지 분류하는 것

추상화 —> 객체지향 프로그래밍

 

1. 대체 가능성

 : child는 parent를 추상화할 수 있다

2. 내적 동질성

 : 오버라이딩 속성을 실제 구현한 child에 접근해서 사용

3. 은닉 : 최대한 내부 정보를 모르게 함

캡슐화 : ATM기. 몰라도 되는 이상 최대한 감춤

 

변화율이 다르면 프로토콜(의정서)를 넣는다.

 

score / score / block

score클래스는 stage로 위임

 

객체지향 프로그래밍의 Context

 : 인스턴스마다 고유하게 보유되는 메모리

 

함수형 프로그래밍

필요한 자유변수를 함수로 막아서 사용

 

Simplex와 Multiplex

 

 

코드스피츠 78 - ES6+함수와 OOP 5회차

  • OOP로 구현한 TodoApp
  • 라이브 코딩 진행

Mutable vs immutable

객체 컨텍스트(객체지향) vs 값 컨텍스트

객체 context로 간다면 비교 동작도 필요하다.

참조로 식별되어야지 값 컨텍스트가 되면 안된다. (장 보기 라는 태스크가 2개여도 다른 값이다)

객체지향은 객체(ref)값으로 확인, 직접 값(중복가능)으로 확인하지 않는다.

외부에 값을 넘길 때에는 박제해서 넘긴다.

 

*테스트 주도 개발!

코드를 짜면 바로바로 확인해야한다.

쉬울 떄 확인해야 덜 위험하고 덜 두렵다.

 

 

코드스피츠 78 - ES6+함수와 OOP 6회차

  • OOP로 구현한 TodoApp 리팩토링
  • 고도화 라이브 코딩
반응형