OLOO 스타일 코드의 특징
1)위임시 상태값은 위임하는 쪽에 두고 위임받는 쪽에 두지 않는다.
2)명칭이 뒤섞이는 일은 피해한다. (cf. 클래스는 오버드라이를 위해 명칭을 같게 한다.)
3)this를 이용하여 바인딩. Task의 this는 이를 link한 XYZ가 해당 함수 또는 프로퍼티 호출시 this에 바인딩
작동 위임 이란 찾으려는 프로퍼티/메서드 레퍼런스가 객체에 없으면 다른 객체에 없으면 다른 객체로 수색 작업을 위임, 객체들이 서로 수평적으로 배열된 상태에서 발생한다는 것이 포인트
상호위임 은 허용되지 않는다.
6.2 클래스 vs 객체
OLOO를 사용하면 생성 및 초기화 과정을 굳이 한곳에 몰아넣고 실행하지 않아도 된다!
6.3 더 간단한 디자인
탈클래스 해라~
6.4 더 멋진 구문
단축 메서드를 쓰면 좋은데 다음과 같은 단점이 있다.
재귀, 이벤트 (언)바인딩 등에서 자기 참조가 어려워 진다.
(자기 참조에 사용할 수 있는 어휘적 식별자가 없다.)
이를 위해
baz: function {}
보다는
baz: function baz(){}
아래와 같이 사용하기를 권한다.
6.5 인트로스펙션
instanceof 는
a instanceo Foo
의 경우 Foo와의 관계가 아니라
Foo.prototype과의 관계를 알려준다.
덕타이핑은 위험
모든 객체가 [[Prototype]] 위임을 통해 연관된 OLOO 방식에는
인트로스펙션이 꽤 깔끔하다.
※ instanceof 연산자는 클래스와 연관되어 보이므로 왠만하면 사용하지 말자
isProtypeOf 사용!
6.1 위임 지향으로 가는 길
6.1.1, 6.1.2
클래스: 인스턴스화하면서 상속한 클래스의 내용을 다 복사 위임: 작동만 위임
OLOO 스타일 코드의 특징 1)위임시 상태값은 위임하는 쪽에 두고 위임받는 쪽에 두지 않는다. 2)명칭이 뒤섞이는 일은 피해한다. (cf. 클래스는 오버드라이를 위해 명칭을 같게 한다.) 3)this를 이용하여 바인딩. Task의 this는 이를 link한 XYZ가 해당 함수 또는 프로퍼티 호출시 this에 바인딩
작동 위임 이란 찾으려는 프로퍼티/메서드 레퍼런스가 객체에 없으면 다른 객체에 없으면 다른 객체로 수색 작업을 위임, 객체들이 서로 수평적으로 배열된 상태에서 발생한다는 것이 포인트
상호위임 은 허용되지 않는다.
6.2 클래스 vs 객체
OLOO를 사용하면 생성 및 초기화 과정을 굳이 한곳에 몰아넣고 실행하지 않아도 된다!
6.3 더 간단한 디자인
탈클래스 해라~
6.4 더 멋진 구문
단축 메서드를 쓰면 좋은데 다음과 같은 단점이 있다.
이를 위해
보다는
아래와 같이 사용하기를 권한다.
6.5 인트로스펙션
instanceof 는
의 경우 Foo와의 관계가 아니라 Foo.prototype과의 관계를 알려준다.
덕타이핑은 위험
모든 객체가 [[Prototype]] 위임을 통해 연관된 OLOO 방식에는 인트로스펙션이 꽤 깔끔하다.
※ instanceof 연산자는 클래스와 연관되어 보이므로 왠만하면 사용하지 말자 isProtypeOf 사용!