🔠 Typescript

enum과 object literal

enum → 간단한 상수 값의 경우 적합
object literal → 복잡한 구조 + 다양한 데이터 타입이 필요한 경우에 적합

enum

• 열거형 데이터 타입 / number, string만 대입 가능

• 상수의 그룹화에 사용

• 코드의 가독성을 높이고 명확한 상수 값을 정의할 수 있다

• 컴파일 시에 자동으로 숫자 값으로 매핑되어 따로 값을 할당할 필요가 없다

object literal

• 객체 리터럴은 key + value로 구성된 객체를 정의하는 방식이다

const obj = {
  a: [1,2,3],
  b: 'b',
  c: 4
}

• 어떠한 타입의 값도 대입할 수 있다 -> 유연한 구조

• 코드 내에서 사용 전 할당되어야하기 때문에 런타임 에러를 방지할 수 있다

사용례

• enum -> 간단한 상수 값을 그룹화해서 관리할 때
  / 각 멤버의 값이 변하면 안된다

• object literal -> 복잡한 구조와 다양한 데이터 타입을 사용해야할 때
  / 멤버의 값이나 데이터 타입을 마음대로 변경할 수 있다

유틸리티 타입

Partial <T>

• 타입 T의 모든 속성을 선택적으로 만든다

• 기존 타입의 일부 속성만 제공하는 객체

interface Person {
  name: string;
  age: number;
}

const updatePerson = (person: Person, fields: Partial<Person>): Person => {
  return { ...person, ...fields };
};

const person: Person = { name: "Spartan", age: 30 };
const changedPerson = updatePerson(person, { age: 31 });

• name 속성만 있는 경우, age 속성만 있는 경우, 둘 다 있는 경우 등 핸들링이 되는 프로퍼티만 정의

• 없는 속성이 추가하거나 하는 경우는 불가능

Required <T>

• Partial <T>와 반대로 타입 T의 모든 속성을 필수적으로 만든다

• T타입 객체에 모든 속성이 반드시 전부 제공되는 객체를 생성해야한다

interface Person {
  name: string;
  age: number;
  address?: string; // 속성? 선택적 속성
}

• 선택적 속성도 필수적으로 받아야할 경우 -> address 입력도 필수 사항이 된다

type RequiredPerson = Required<Person>;

Readonly <T>

• 타입 T의 모든 속성을 읽기 전용으로 만든다

• 완전한 불변 객체로 취급할 수 있다 -> 객체의 상수화

interface DatabaseConfig {
  host: string;
  readonly port: number; // 인터페이스에서도 readonly 타입 사용 가능해요!
}

const mutableConfig: DatabaseConfig = { // 가변
  host: "localhost",
  port: 3306,
};

const immutableConfig: Readonly<DatabaseConfig> = { // 불변
  host: "localhost",
  port: 3306,
};

mutableConfig.host = "somewhere";
immutableConfig.host = "somewhere"; // 오류! -> 불변 객체화

Pick <T, K>

• 타입 T에서 K 속성들만 선택하여 새로운 타입을 만든다

• 타입의 일부 속성만 포함하는 객체를 쉽게 생성할 수 있다

interface Person {
  name: string;
  age: number;
  address: string;
}

type SubsetPerson = Pick<Person, "name" | "age">;

const person: SubsetPerson = { name: "Spartan", age: 30 };

• name과 age 속성만 선택해서 새로운 타입 구성

Omit <T, K>

• Pick <T, K>와 반대 -> 타입 T에서 K 속성만 제외한 새로운 타입을 만든다

interface Person {
  name: string;
  age: number;
  address: string;
}

type SubsetPerson = Omit<Person, "address">;

const person: SubsetPerson = { name: "Alice", age: 30 };

• address 속성만 제외한 새로운 타입

Class

Class란?

• 객체를 만들기 위한 틀

• 속성과 메소드로 구성

  • 속성 - 객체의 성질

  • 메소드 - 객체의 성질을 변화시키거나 객체에서 제공하는 기능

• 클래스를 기반으로 생성된 객체 -> 인스턴스(instance)

Class 정의 및 접근 제한자

• class 키워드를 사용해서 정의

• new 키워드를 사용해서 생성

• 생성자(constructor)

  • 인스턴스를 생성할 때 자동으로 호출

  • 클래스 내에 오직 하나만 존재할 수 있다

  • 객체의 속성을 초기화

  • 객체가 생성될 때 꼭 되어야하는 초기화 로직

• 접근 제한자

  • public - 클래스 외부에서도 접근이 가능한 접근 제한자
    접근 제한자를 선언하지 않았을 경우 기본으로 public

  • private - 클래스 내부에서만 접근이 가능한 접근 제한자
    대부분 private로 설정 -> 외부에서 직접적으로 객체의 속성을 변경할 수 없게 제한

  • protected - 클래스 내부의 해당 클래스를 상속받은 자식 클래스에서만 접근이 가능한 접근 제한자

상속(inheritance)

상속이란?

• 기존 클래스의 속성과 메소드를 물려받아 새로운 클래스를 정의

• 코드의 반복을 줄인다

• extends 키워드를 사용해서 상속받는다

• super 키워드는 자식 클래스가 부모 클래스를 참조하는데 사용

• 자식 클래스가 부모 클래스의 메소드 등을 새로 정의하는 것 -> 오버라이딩(overriding)

서브 타입, 슈퍼 타입

• 서브 타입

  두 개의 타입 A와 B가 있고 B가 A의 서브타입이면 A가 필요한 곳에는 어디든 B를 안전하게 사용할 수 있다.

• 슈퍼 타입

  두 개의 타입 A와 B가 있고 B가 A의 슈퍼타입이면 B가 필요한 곳에는 어디든 A를 안전하게 사용할 수 있다.

• any는 모든 것의 슈퍼 타입

upcasting, downcasting

• upcasting

  • 서브 타입 -> 슈퍼 타입으로 변환하는 것

  • 타입 변환은 암시적 -> TS가 자동으로 수행

  • 서브 타입을 슈퍼 타입으로 다루면 유연하게 활용할 수 있기 때문에 사용한다

• downcasting

  • 슈퍼 타입 -> 서브 타입으로 변환하는 것

  • as 키워드로 명시적으로 타입 변환을 해야한다

  • 자식의 메소드를 사용해야할 경우에 사용

추상 클래스

추상 클래스란?

• 인스턴스화 할 수 없는 클래스

• 상속을 통해 자식 클래스에서 메소드를 제각각 구현하도록 강제하는 용도

• 기본 메소드는 정의 가능 하지만 핵심 기능의 구현은 전부 자식 클래스에 위임

• abstract 키워드를 사용하여 정의

• 1개 이상의 추상 함수가 있는 것이 일반적

인터페이스(interface)

인터페이스란?

• TS에서 객체의 타입을 정의하는데 사용

• 객체가 가져야하는 속성과 메소드를 정의

• 인터페이스로 구현한 객체는 반드시 인터페이스를 준수해야한다

• 코드의 안정성을 높이고 유지 보수성을 향상시킨다

추상클래스와의 차이

구현부 제공 여부

• 추상 클래스

  • 클래스의 기본 구현을 제공

• 인터페이스

  • 객체의 구조만 정의

상속 메커니증

• 추상 클래스

  • 단일 속성만 지원

• 인터페이스

  • 다중 상속 지원

  • 하나의 클래스는 여러 인터페이스를 구현할 수 있다

구현 메커니즘

• 추상 클래스

  • 상속받은 자식 클래스는 반드시 추상 함수를 구현해야한다

• 인터페이스

  • 인터페이스로 구현한 클래스는 인터페이스에 정의된 모든 메소드를 전부 구현해야한다

사용례

• 추상 클래스

  • 기본 구현을 제공하고 상속을 통해 확장하는 경우

• 인터페이스

  • 객체가 완벽하게 특정 구조를 준수하도록 강제하고 싶은 경우

객체 지향 설계 원칙 - S.O.L.I.D

S(SRP, 단일 책임 원칙)

• 클래스는 하나의 책임만 가져야한다

• 가장 기본적이고 중요한 원칙

e.g
유저 클래스는 유저와 관련된 행위만 수행해야한다.
이메일 전송 등 x

O(OCP. 개방 폐쇄 원칙)

• 확장에 대해서는 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다

• 기존 코드를 변경하지 않고 기능을 확장할 수 있어야 한다

• 인터페이스나 상속을 통해 해결

L(LSP. 리스코프 치환 원칙)

• 서브 타입은 기반이 되는 슈퍼타입을 대체할 수 있어야 한다

• 자식 클래스가 부모 클래스의 기능을 수정하지않고 부모 클래스와 호환이 되어야 한다

I(ISP. 인터페이스 분리 원칙)

• 해당 클래스에게 무의미한 메소드의 구현을 막자

• 인터페이스를 필요한 만큼만 정의하고 클래스는 입맛에 맞는 인터페이스를 구현하도록 유도

D(DIP. 의존성 역전 원칙)

• 웹 서버 프레임워크에서 많이 나오는 원칙

• 하위 수준 모듈(구현 클래스)보다 상위 수준 모듈(인터페이스)에 의존을 해야한다

💻 TCP

헤더(header)

• 헤더에는 순서 정보, 확인 응답 번호(ACK), 윈도우 크기 등의 정보가 들어간다

• 16비트 체크섬을 사용해 패킷의 데이터 무결성을 확인한다

순서 보장

• TCP에서는 패킷이 순서대로 도착하도록 시퀀스 번호를 부여한다

• 패킷이 손실되거나 잘못된 순서로 도착할 경우 재전송 요청(ACK)을 보내 해당 패킷을 다시 요청한다

청크 단위 전송

• TCP는 데이터를 작은 청크(데이터 블록)으로 나누어 전송한다

• 각 청크는 시퀀스 번호로 추적되고 손실된 청크는 재전송된다

패킷 조립 및 순서 맞추기

• 수신자가 패킷을 받으면 시퀀스 번호를 확인해 순서를 맞춘다

• 순서가 맞지 않으면 해당 패킷을 버퍼에 대기시킨 후 누락된 패킷을 재요청해서 전체 데이터를 완성한다

h e l l o -> <Buffer 48 65 6c 6c 6f>
48 1 // 도착
65 2 // 도착
6c 4 // 도착하지만 3번 패킷이 누락되어 대기 상태
6c 3 // 재요청 후 도착, 4번 패킷과 함께 처리됨
6f 5 // 도착