OOP의 바탕이 되는 Class를 구현하는 것에 있어서 4가지의 중요한 원칙이 있다.
추상화(Abstraction), 캡슐화(Encapsulation), 상속(Inheritance), 다형성(Polymorphism) 이 그것들이다.
= variety(다양성)
class함수는 constructor함수보다 data와 behavior를 하나의 코드block에 훨씬 깔끔하게 정리할 수 있다.
class를 사용할 때, 알아 둬야할 점이 3가지 있다.
첫 번째, class함수는 선언문의 형태로 선언했더라도 hoist 되지 않는다. 함수 선언문 같은 경우 hoisted 되기 때문에 code로 선언하기 전에 그 함수를 사용할 수 있다. 하지만 class함수는 그럴 수 없다.
두 번째, class는 일급객체이므로 다른 함수에 passing 하거나 다른 함수 안에서 return할 수 있다. 왜냐하면 class 함수는 background에서 특별하게 취급되는 함수이기 때문이다.
일급객체에 대한 설명참고
세 번째, class 함수 내의 body 부분은 항상 strict mode에서 실행된다.
용어를 정확히 하자. inheritance가 '상속'이란 명사로 번역되면서 이해하는 게 혼란스러운 것 같다. 명사로 번역할 것이라면 '유전'으로 번역하는 게 직관적으로 훨씬 더 이해하기 쉽다.
Inheritance를 유전자의 관점에서 해석할 때, 유전을 '하는' 것이 아니라 유전을 '받는' 것이다. 애초에 유전이라는 것은 부모가 주체적으로 할 수 있는 것인가?
예를 들어서, 내가 부모인데 '목 뒤의 점'이라는 특징을 내가 유전하고 싶다고 해서 선택적으로 할 수 있는 게 아니다. 그렇기 때문에 '유전'이라는 단어는 항상 수동적인 의미로 쓰여야 한다.
항상 자식 입장에서 그 특징을 '유전을 받는' 것이지, 부모의 입장에서 '유전을 하다', '유전을 했다' 라는 문장은 논리적으로 말이 안된다는 것이다. 예를 들어서, 어떤 부모가 "나 임신하면서 목 뒤의 점을 우리 아들에게 유전했어~" 라고 이야기 할까? 그래서 inherit이라는 동사의 사전적인 의미도 '상속받다', '물려받다' 이다.
하지만 inheritance가 공식적으로 한국에서 '상속'이라는 명사로 번역되면서 이해하기가 어렵다. 원래의 명사적인 뜻은 '상속 받은 재산'으로 '받은' 이라는 수동적인 의미를 포함하는데 '상속'이라는 단일 명사로 번역 되어버리면서, '상속을 하다' 처럼 주체적인 의미를 포함하는 문장으로도 쓰일 수 있어 혼동이 되기 때문이다. 예를 들어서, 내가 부모라면 아들에게 "내가 죽으면 너한테 남은 재산을 상속 해줄게" 라고 말하는 것은 쓰일 법한 문장이고 머리로도 이해가 된다.
즉, 유전자와는 다르게 재산은 부모의 입장에서 상속을 하는 주체적인 표현이 가능하기 때문에 한국인의 관점에서 inheritance를 직관적으로 이해하는 게 힘들다.
또한 상속이라는 단어는 1차원적으로 부모가 죽은 후에 하는 것으로 인식되기 때문에, 처음 inheritance를 접하는 사람으로써는 prototype에게 propery를 상속받는다고 하면 "prototype이 죽는 건가?"라는 이상한 혼동까지 올 수 있다. 반면, 유전으로 이해하면 유전은 부모가 살아있을 때 하는 것이기 때문에 이해가 더 직관적이다.
결과적으로 inheritance를 '상속' 보다는 '유전'으로 유전적인 특징을 물려받는 느낌으로 이해하는 게 좀 더 Prototype을 이해하는 것에 도움이 된다.
Student is a type of Person = Student extends Person
Now first, remember that encapsulation basically means
to keep some properties and methods private inside the class
so that they are not accessible from outside of the class.
Then the rest of the methods are basically exposed
as a public interface, which we can also call API.
첫 번째로, class 바깥의 코드가 예기치 않게 class 안에 있는 data를 manipulate하는 것을 방지하기 위해서이다. 위의 예제처럼 수동으로 object내의 property를 조작하는 식의 코드를 지양해야하고 public API인 예치 method를 통해 class 내부의 data를 manipulate 하는 것이 안전하다.
두 번째로, 적은 수의 public 메서드들만 노출 하기 때문에 다른 내부 메서드들을 변경할 때 혹여 코드를 break 할까 걱정하지 않아도 된다.
하지만 자바스크립트 class 에서는 실제로 data privacy나 encapsulation을 아직 완벽하게 지원하고 있지는 않다. 여기서 제시하는 방법들은 private한 class 영역을 만들기 위해서 개발자들끼리 정한 convention 같은 것이다.