Til Home

2020-08-03-TIL

Fact

  • 5일차!!

Feelings

  • 2주차 밖에 안됬는데 힘들다 ㅠㅠ

Findings

클래스와 오브젝트, 인스턴스

  • 클래스는 객체의 구조, 속성 및 행위를 정의한다.
  • 사람들은 무심코 승용차, 버스, 트럭들을 보고 ‘차’라고 분류를 한다. 이 분류 한 것을 type이라고 한다.
  • 이 type을 instance화 한게 객체이다. 위의 예를 들어 보자면 승용차, 버스, 트럭이 객체이다.
  • class는 이 객체를 표현 할때 쓸 수 있는 도구이다.

객체 상속과 다향성

  • 객체로 부터 상속을 받으면 그 상속 받은 객체의 속성과 행위를 쓸 수 있다.
  • 다형성은 상속받은 행위중 overwrite를 해서 다르게 작동 하게끔 만들어서 쓰는게 다형성이다.
class A {
  constructor() {
    this.value = this.getValue();
  }
  getValue() {
    return 1;
  }
}

>const a = new A();
> a.getValue(); // 1

class B extends A { // A로 부터 상속
  constructor() {
    super();
  }
} 

>const b = new B();
> b.getValue(); // 1

class C extends B { //B로 부터 상속
  constructor() {
    super();
  }
  getValue() { //덮어 쓰고 인하여 다향성
    return 2 + super.getValue();
  }
}

>const c = new C();
> c.getValue(); // 3

Class 와 Prototype

  • js에선 class는 함수의 한 유형이다.
  • class 가 없었을때 함수로 선언을 했다. 그래서 상속 같은 느낌을 나게 하는 prototype chaining을 써서 함수를 만들때 마다 중복 메서드를 넣지 않고 prototype 에 저장해서 가져다 쓴다.
  • class를 쓰면 굳이 prototype.메서드 를 해서 따로 넣어 주지 않아도 알아서 해준다.
  • 최상위 일수록 추상화, 하위 일 수록 구체적 이 과정을 procedure이라고 한다. 절차적인 내용을 함수 단위를 procedure 추상화, 기능 분해라고 한다.

    • main => (input, process, output) => (validate, save format)
  • 다형성 - polymorphism

this와 super

  • super은 상속을 받은 것을 쓰기 위해서 불러올때 쓰는것이다.
  • this는 현제 instance의 속성/행위를 쓸때 붙이는 것이다.

객체 인스턴스 비교 방법

  • 레퍼런스 비교 vs 속성/값 비교

    • 인스턴스의 레퍼런스 비교를 하면 효율이야 좋겠지만… === 를 하면 무조건 false 나올듯…
    • 인스턴스 속성/값 비교하기 위해서 왠만하면 shallow equality 혹은 값이 배열, 객체등 primitive 값이 아닌게 들어 있다면 deep equality를 써야지만 원하는 값을 얻을 수 있다.

SOLID 원칙

두문자 약어 개념
S SRP 단일 책임 원칙 (Single responsibility principle) - 한 클래스는 하나의 책임만 가져야 한다.
O OCP 개방-폐쇄 원칙 (Open/closed principle) - “소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.”
L LSP 리스코프 치환 원칙 (Liskov substitution principle) - “프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.” 계약에 의한 설계를 참고하라.
I ISP 인터페이스 분리 원칙 (Interface segregation principle) - “특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.”[4]
D DIP 의존관계 역전 원칙 (Dependency inversion principle) - 프로그래머는 “추상화에 의존해야지, 구체화에 의존하면 안된다.”[4] 의존성 주입은 이 원칙을 따르는 방법 중 하나다.

SOLID SRP

이 원칙의 목적은 클래스/모듈에 대한 단일 책임을 갖는 것이다. 즉, 클래스나 모듈이 하나의 문제만을 해결해야 한다고 말할 수 있다. 그러 함으로 코드를 더욱 응집력 있게 만들어 테스트 하고 유지 보수 하기 쉽게 만든다.

SOLID LSP

“프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.

Future Action

  • 문제 풀때 요구 조건을 저 구석 마지막 페이지에 적어서 처음 부터 다시 해야 했다. 그러나 시간이 부족해서 못했다. 다음에는 처음 부터 끝까지 읽은 후에 계획 짜고 문제 풀도록 하자.