TIL 53일차(20240312)

오늘은 반드시 완강한다!!!

✏️ 추상 클래스 by abstract

• 추상 클래스 상속받은 클래스는 반드시 get을 사용해야한다.

✏️ 인터페이스 (규약 - typescript에서는)

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

• 코드의 안정성을 높이고 유지 보수성을 향상시킬 수 있음

• ✨ 추상 클래스와의 다른 점

  • 추상클래스
    • 클래스의 기본 구현을 제공
    • 단일 상속만 지원
    • 추상 클래스를 받은 자식 클래스는 반드시 추상 함수를 구현해야 함
    • 기본 구현을 제공하고 상속을 통해 확장하는데 초점을 맞출 때 사용
  • 인터페이스
    • 객체의 구조만 정의하고 기본 구현을 제공하지는 않음
    • 다중 상속을 지원 (1 클래스 多 인터페이스)
    • 인터페이스를 구현하는 클래스는 인터페이스에 정의된 모든 메서드를 전부 구현
    • 객체가 완벽하게 특정 구조를 준수하도록 강제할 때 사용

  ---

🚩 객체 지향 설계 원칙 SOLID

🌟🌟🌟🌟🌟 S (SRP, 단일 책임 원칙)

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

🌟 O (OCP, 개방 폐쇄 원칙)

• 클래스는 확장에 대해서는 열려 있어야 하고 수정에 대해서는 닫혀 있어야 함
• 클래스는 기존 코드를 변경하지 않고 기능을 확장할 수 있어야 함
  -> 인터페이스나 상속 잘 활용하기!!

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

• 서브타입은 기반이 되는 슈퍼타입을 대체할 수 있어야함
• 자식 클래스는 부모 클래스의 기능을 수정하지 않고도 부모 클래스와 호환되어야함
• 논리적으로 엄격하게 관계가 정립되어야함

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

• 클래스는 자신이 사용하지 않는 인터페이스의 영향을 받지 않아야 함
• 인터페이스를 너무 크게 정의하기보다는 필요한 ㅂ만큼만 정의하고 클래스는 딱 필요한 인터페이스들만 구현하도록 유도하기

🌟 D (DIP, 의존성 역전 원칙)

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

---

✏️ 레이어드 아키텍쳐 패턴

🌞 프리젠테이션 계층 (컨트롤러)

• 클라이언트와 통신을 직접적으로 담당하며 클라이언트의 요청을 해석하고 응답하는 계층
• 비즈니스 계층으로 요청을 위임하고 받은 결과를 응답하는 역할만 수행

🌞 비즈니스 계층 (서비스)

• 비즈니스 로직을 수행하는 계층으로 데이터 계층과 통신함

🌞 데이터 계층 (레포지토리)

• 실제 데이터베이스(RDBMS or NoSQL)에 접근하는 계층

🌛 레이어드 아키텍처 패턴의 주요 특징

• 의존성: 각 계층은 가장 가까운 하위 계층의 의존성을 주입받음
• 독립성: 각 계층은 다른 계층의 역할을 침범하지 않음

---

✏️ Nest.js 개념

🌞 main.ts

• 진입점 파일로 이름을 변경해서는 안됨

🌞 모듈

• 애플리케이션의 특정 부분을 캡슐화하며, 관련된 컴포넌트, 서비스, 다른 모듈들을 그룹화함
• imports
  • 현재 모듈에서 사용하려는 다른 모듈들의 목록을 정의
  • 필요한 프로바이더(서비스)를 제공함
• controllers
  • 현재 모듈과 관련된 컨트롤러의 목록을 정의
  • 해당 모듈의 요청 처리 로직을 담당
• providers
  • 현재 모듈에서 사용하거나 제공하는 서비스, 리포지토리, 팩토리 등의 목록을 정의
  • 비즈니스 로직 처리나 데이터 엑세스와 같은 작업을 수행
• exports
  • 현재 모듈에서 다른 모듈로 제공하려는 서비스의 목록을 정의

🌞 데코레이터

• 앞에 '@'이 붙음
• 해당 클래스나 함수가 어떤 역할을 수행하는지 Nest.js에 알려주는 역할

🚀 모듈 추가적 지식

• service + providers (서비스를 모듈로 감싸지 않을 때)
  • 서비스가 특정 모듈 내에서만 사용되고 다른 모듈에서는 사용되지 않을 때 사용
• module exports + imports
  • 해당 서비스를 여러 모듈에서 공통으로 사용할 때

---

🌞 컨트롤러

• @Controller() 작성하여서 해당 클래스가 컨트롤러 역할을 하는 것을 Nest.js에 알림
• DI (의존성 주입)

  constructor(private readonly appService: AppService) {}

  • (생성자를 통한 DI를 이용하여) 컨트롤러는 서비스를 반드시 의존해야 함
• 이외의 데코레이터:

  @Get, @Post, @Put, @Patch, @Delete

🌞 서비스

• @Injectable() : controller에서 DI하기 위해 명시함
• 서비스 객체는 리포지토리를 의존하며 비즈니스 로직 실행을 담당함
• 서비스는 리포지토리를 반드시 의존해야 하며 이는 생성자를 통한 DI로 해결해야함

---

🌞 IoC (제어 역전)

• 객체의 생명주기 관리를 외부 (Nest.js IoC 컨테이너)에 위임
• IoC 원칙을 사용하면 AppController는 AppService의 구체적인 구현보다는 인터페이스의 추상 클래스에 의존함 -> 서비스 자체가 변경되어도 관계없이 사용할 수 있음
• ⭐ 코드의 결합도가 감소, 유연성과 테스트 용이성을 향상시킴

🌞 DI (의존성 주입)

• ex) constructor(private readonly appService: AppService)
• 위의 예제에서 appService의 인스턴스는 DI 컨테이너에 의해 생성되고 관리됨 -> 제어 역전!