[코드스피츠] Javascript의 객체지향

intro

객체지향에서는 모든 것을 객체로 받자!!! no value!
age=23 → new Age(23)
값을 쓸 수 있는 건 생성자밖에 없는거야

---

Value

• 값이란 number nan string .. primitive 속성
• 메모리 주소와 상관없이 그 알맹이가 같으면 같다고하는것
• 계속 복사본을 만들기 때문에 상태 변화에 안전하다
• 연산을 기반으로 로직 전개하게 된다

identifier

• 주소값을 비교하는것
• 내부의 상태관리를 해야함 왜냐면 mutable이기 때문에
• 하나의 원본 왜냐면 참조니까
• 연산이 아니라 메세지를 기반으로 로직 전개
  ⇒ 메세지 기반으로는 내가 만든데 까지만 구동되는 프로젝트를 만들 수 있다.

결론

⇒ 객체지향은 value context를 지향하지 않기로 하는 것
⇒ 둘 중 하나의 컨텍스트만 사용하렴

🤯그럼 함수형은??
🤯연산을 통해서 새로운 값을 만들어내니까 ??함수형이 나옴??

---

Polymorphism 다형성 = 대체가능성 + 내적일관성

// 코드 넣기

• 자식은 부모를 대체할 수 있는 것.
• 확장된 클래스는 대상 클래스의 대체 할 수 있음

대체가능성

자식이 부모를 대체할 수 있는것

    const worker = class{
    	run(){ console.log("working")}
    	print(){ this.run() }
    }
    
    const hardworker = class{
    	run(){ console.log("hard working")}
    }
    
    const worker = new hardworker(); // new 로 생성된 객체가 바인딩 되기 때문에
    worker.print() // hard working

⇒ 내적일관성 : 원본 class를 유지하려는 속성
js가 이 규칙을 따르는 것 뿐이지. js가 이렇게 하기로 한 게 아님
객체지향 언어는 이런 약속을 지킬꺼라고 생각하는 것

---

Polymorphism of Prototype

js에서 다형성을 구현하는 방식

[ prototype 그림]

내적일관성은
대체가능성 instanceOf
proto가 는 cunstructor가 해당하는지 확인하는것

처음에 확인했는데 실패하면 그다음 워커를확인

👏🏻 js는 객체지향언어인가요?
ㅇㅇ. Polymorphism이 언어 차원에서 지원되니까. 객체지향언어를 쓴다고 객체지향을 하는건 아니다

---

Object essentials 객체란, 객체의 책임은?

// code

• hide state (데이터 은닉) : 객체의 속성의 조건은 모두 private
  왜냐면 모든건 객체로 봐야되는데 속성이 노출되면 값이 보여지니까!
• encapsulation (캡슐화) : 외부에 기능을 캡슐화하는것
  • 기능 메소드에서 안에서 무슨일이 일어나는지 모르고 추상화 되어있는 의미로 알아야해
  • 따라서 get name(){}에서 이게 카모플라쥬인지 아니면 이름인지 모른다.

객체지향하려면 여유와 바른마음이 필요합니다! ㅎㅎㅎ

[객체가 무조건 가져야 하는 책임]

• Encapsulation of Functionality
  • setAge(x) ⇒ setChild setAuthoritication.. 어떤 목적을 위해서 기능의 목적을 위해 나이를 받게 되는 것.
• Maintenance of State = 상태관리의 책임
  - setAge() 같이 상태관리를 밖에서 하게 내보내는 것은 나쁜 예
  ⇒ 왜 이걸 주로 책임으로 보는가 isolation of change!를 위해서

변화에 대한 격리 (=isolation of change)

위의 조건을 가져야지 변화에 대해서 격리할 수 있는 것

---

알려진 기본 설계 요령 = SOLID

solid

• SRP 단일책임

  • 나는 이런 경우에만 수정할꺼야
  • 산탄총 수술. shotgun sergery

• OCP 개방폐쇄

  • open : extends나 implement를 하는것
  • close: 새롭게 extends를 하게 하라 기존 코드를 고치려고 하지말고 새로운 객체를 만들어서 새로운 문제를 새로운 해결을 하도록 하라고 해라
    ⇒ 추상화

• LSP 업캐스팅

  • 추상층은 추상적으로 해야해.
  • 추상클래스가 너무 구체적이여서 업캐스팅이 안되는 문제
  • 그래서 다리이동은 인터페이스로 분리하는 것
    [ 그림 ]

• ISP 인터페이스 분리 [추가]

  • 추상화로 분리
  • 상태의 본질인 지갑이 나한테 있으니까 위임도 못하고 다 자기 메소드로 들고있게 되는데.
  1. 소유를 사용 : 나의 분신 사장, 아빠, 남편을 만든다.
     • ㅇㅇㅇ의 지갑을 이용해서 월급 용돈을 준다.
  2. 인터페이스로 분리 (표)
     • as 아빠 , as 사장
     • 아니면 new 아빠, new 사장

• DIP : 의존성역전 다운캐스팅 금지

  • 의존성은 언제나 부모쪽으로 흘러야함
  • DI 의존성주입은 IOC의 일부

---

용어

DI to 최소 용어 정리하기

---

Message!

단일 책임을 준수하는 객체망이 문제를 해결

책임 이상의 업무일때 내가하거나 다른 객체에게 의뢰해야 함
의뢰 = 메세지!
메세지의 구성

• 메세지 : 의뢰내용
• 오퍼레이션 : 이런이런걸 해야한다는 명시
  어떤 메소드를 호출할지 모르고 보내는 것
  수신할 객체가 제공할 서비스
• 메소드
  실제로 일을 처리하는 것

⇒ 동적바인딩이 있는 언어에서는 오퍼레이션과 메소드는 다를 수 있음
⇒ 오퍼레이션과 메소드를 분리해서 런타임에서 원하는걸

동적바인딩

오퍼레이터가 어떤 메소드가 실행될지 런타임에 결정하는 것

---

의존성

의존성의 종류

영구적인 연관

• 상속
  부모에 완전 묶여있는 것, 상속은 부모객체가 변하면 다 변경되는것
• 연관
  필드에 그 객체 타입을 알고 있는 것
  임시의존
• 의존 dependency
  오퍼레이션 실행할 때만 의존됨. 인자 메소드 단위.
  호출안하면 영원히 의존하지 않을 수도 있다.

의존성이 높으면

• 수정 난리, 수정이 어려움
• 순환 의존성 a→b→c→b 그래서 a가 b를 아는 한가족

---

DI 의존성 역전

규칙

• 다운캐스팅 금지
• 폴리모피즘 추상인터페이스 사용

코드

    const worker = class{
    	run(){ console.log("working")}
    	print(){ this.run() }
    }
    
    const hardworker = class{
    	run(){ console.log("hard working")}
    }
    
    const worker = new hardworker(); // new 로 생성된 객체가 바인딩 되기 때문에
    worker.print() // hard workin

Manager class는 확장된 쪽이 아니라 추상화 된 쪽을 가지고 수행함으로서 의존성을 역전 된다
왜냐하면 run은 worker의 확장이므로
=> DIP와 OCP는 주로 한번에 해결됨

---

IOC

제어역전?

• control : flow controll 흐름제어
• 역전 : 역으로 대체해주는 것을 만들어주겠다. 쟤한테 시킬래
• 제어를 추상화
• 똑같은걸 만들고 차이점만 공급받도록한다.

제어역전의 실제구현

• 전략 템플릿 < 컴포짓 < 비지터

• 그런데 이런 코드로는 뷰를 조작 할 수는 없음

• 원하는 것을 적당한것을 끼워넣고 싶을 때는?
  ⇒ 비지터 + 추상팩토리메소드 패턴 로 구현가능
  // 뷰 제어역전 코드

framework library

프레임워크는 제어의 역전을 해주는 것 ⇒ 그래서 생명주기가 있는 것
ioc framework