이정훈

이정훈

기록을 습관화하자

0201 - 0207

0201

Promise

  • promise란 자바스크립트에서 제공하는 비동기를 간편하게 처리할 수 있도록 도와주는 오브젝트
  • 정해진 장시간의 기능을 수행하고 나서, 성공적으로 수행하면 성공 메시지와 함께 결과 값을, 에러를 발견했다면 에러를 반환
  • 중점으로 봐야할 것은 비동기처리가 성공했는지 실패했는지의 상태와 프로미스를 만드는 Producer vs 프로미스를 사용하는 Consumer

Producer

새로운 프로미스가 만들어 질때는, executor라는 함수가 자동적으로 실행된다.
-> 프로미스를 만들면서 바로 실행되기 때문에 상황에 맞게 프로미스를 사용해야 한다.

const promise = new Promise((resolve, reject) => {
  // 네트워크나 파일 읽기등 무거운 일을 한다.
  console.log("doing something");
  setTimeout(() => {
    //resolve('ellie');
    reject(new Error("no network")); // reject는 보통 Error 오브젝트를 통해서 값을 전달
  }, 2000);
});
  • 비동기 처리 성공 시 resolve, 실패 시 reject에 값을 전달한다.

Consumer

promise
  .then((value) => {
    //then은 promise가 성공적으로 마치고나면 resolve의 인자값을 value로 전달한다.
    console.log(value);
  })
  .catch((error) => {
    //then의 return값이 Promise이기 때문에 다시 catch를 이어서 호출할 수 있다. => chaning
    console.log(error);
  })
  .finally(() => {
    console.log("finally"); //성공이던 실패이던 호출한다.
  });

0202

Async

  • 프로미스 사용의 깔끔한 스타일
  • syntactic sugar - 기존에 존재하는 것을 감싸서 우리가 조금 더 간편하게 쓸 수 있는 api를 제공하는 것

async

  • 코드 블럭이 자동으로 프로미스로 바뀐다.
async function fetchUser() {
  // do network request in 10 secs...
  return "ellie";
}

await

  • async가 붙은 함수 안에서만 사용 가능
async function getApple() {
  await delay(3000);
  return "🍌";
}

-> 동기적으로 처리되는 것처럼 보이게 한다.

0203

  • 자바스크립트를 기본만 하고, 다시 백엔드 공부로 넘어가려고 한다.
  • 우선 스프링의 원리부터 깊게 학습하고, 개념을 깊게 학습하는 것은 백엔드 위주로 해야겠다고 다시 방향을 잡았다.
  • 뷰는 계속해서 사용법을 익히고 그와 관련된 학습들을 조금씩 공부할 예정이다. 하지만 뷰의 기반 언어는 자바스크립트인데, 두 마리 토끼를 모두 잡기에는 시간이 부족해서 선택과 집중을 해야겠다고 생각했다.
    -> 다시 초심으로 돌아와서 백엔드 위주의 깊은 학습을 하고, 뷰는 간단하게 한 번 보고 필요할 때마다 찾아서 공부하는 방식으로 학습을 진행해야겠다.

0204

객체 지향 설계와 스프링

스프링의 핵심 스프링은 자바 언어 기반의 프레임워크로 좋은 객체 지향 애플리케이션을 개발할 수 있게 도와준다.

객체 지향 프로그래밍

  • 프로그램을 객체들의 모임으로 파악하고자 하는 것. 객체는 메시지를 주고받고, 데이터를 처리할 수 있다.
  • 가장 큰 장점은 프로그램을 유연하고 변경이 용이하게 만든다.
    -> 컴포넌트를 쉽고 유연하게 변경하면서 개발할 수 있는 방법

다형성

  • 역할(인터페이스)과 구현(구현 객체)으로 구분하면 세상이 단순해지고, 유연해지며 변경이 편리해진다.
  • 클라이언트는 대상의 역할만 알면 되고, 내부 구조를 몰라도 된다.
  • 클라이언트는 구현 대상의 내부 구조가 변경되거나 대상 자체를 변경해도 영향을 받지 않는다.
  • 객체를 설계할 때 역할과 구현을 명확히 분리

다형성의 본질

  • 혼자 있는 객체는 없고, 수 많은 객체 클라이언트와 객체 서버는 서로 협력 관계를 가지는 것에서부터 시작
  • 인터페이스를 구현한 객체 인스턴스를 실행 시점에 유연하게 변경할 수 있다.
  • 클라이언트를 변경하지 않고, 서버의 구현 기능을 유연하게 변경할 수 있다.

장점

  • 유연하고, 변경이 용이
  • 확장 가능한 설계
  • 클라이언트에 영향을 주지 않는 변경 가능
  • 인터페이스를 안정적으로 잘 설계하는 것이 중요
    -> 역할(인터페이스) 자체가 변하면, 클라이언트, 서버 모두에 큰 병경이 발생하므로

스프링과 객체 지향

  • 스프링은 다형성을 극대화해서 이용할 수 있게 도와준다.
  • 제어의 역전(IoC), 의존관계 주입(DI)은 다형성을 활용해서 역할과 구현을 편리하게 다룰 수 있도록 지원한다.

0205

새로운 프로젝트를 진행하기 위해 팀원과 만나서 회의를 하는 시간을 가졌다. 그 동안 공부하면서 느꼈던 것들을 공유하기도 하고, 아이디어를 통해 프로젝트의 큰 주제를 정하고 꿈을 키웠다. 상당히 재미있는 프로젝트가 될 것 같다는 느낌이 크게 들었다.

  • 우선 프로젝트를 본격적으로 시작하기 전에 실력을 테스트하고 돌아보고자 작은 토이 프로젝트를 진행하기로 했다.
  • Vue, Java, Spring, Mysql을 활용하여 게시판을 작성하고 필요한 기능들을 구현하고자 한다.
  • 스토리보드를 카카오오븐을 이용하여 작성하고 화면과 기능들을 정의하였다.
  • 비록 5개의 화면으로만 구현되어있는 프로젝트이지만, 생각보다 구현해야할 기능이 많았다.
  • 구조를 잡는데에 집중하여 프로젝트를 잘 성공시켜서 더 큰 프로젝트를 하는 데 있어서 자신감을 키울 수 있는 기회가 되었으면 좋겠다.

0206

좋은 객체 지향 설계의 5가지 원칙 (SOLID)

SRP(Single responsibility principle) - 단일 책임 원칙

  • 한 클래스는 하나의 책임만 가져야 한다.
  • 중요한 기준은 변경. 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것
  • ex) UI 변경, 객체의 생성과 사용을 분리

OCP(Open/closed principle) - OCP 개방/폐쇄 원칙

  • 소프트웨어 요소는 확장에는 열려있으나 변경에는 닫혀있어야 한다.
  • 다형성을 활용
MemberRepository m = new MemoryMemberRepository(); //기존 코드
MemberRepository m = new JdbcMemberRepository(); // 변경 코드
  • 구현 객체를 변경하려면 클라이언트 코드를 변경해야 하므로 다형성을 사용했지만 OCP 원칙을 지킬 수 없다.
    -> 객체를 생성하고, 연관관계를 맺어주는 별도의 설정자가 필요하다

LSP(Liskov substiturion principle) - 리스코프 치환 원칙

  • 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
  • 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다는 것, 단순히 컴파일에 성공하는 것을 넘어선다.
  • ex) 자동차 인터페이스의 엑셀은 앞으로 가라는 기능, 뒤로 가게 구현하면 LSP 위반

ISP(Interface segregation principle) - 인터페이스 분리 원칙

  • 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
  • 인터페이스가 명확해지고, 대체 가능성이 높아진다.

DIP(Dependency inversion principle) - 의존관게 역전 원칙

  • 구현 클래스에 의존하지 말고, 인터페이스에 의존해야 한다.
  • 클라이언트가 인터페이스에 의존해야 유연하게 구현체를 변경할 수 있다. 구현제에 의존하면 변경이 아주 어려워짐
  • OCP에서 설명한 MemberService는 인터페이스에 의존하지만, 구현 클래스도 동시에 의존한다.
    -> DIP 위반

객체 지향 설계와 스프링

  • 객체 지향의 핵심은 다형성인데, 이 만으로는 OCP, DIP를 지킬 수 없다.
  • 스프링은 DI와 DI 컨테이너를 제공해서 이를 지킬 수 있도록 지원한다.
  • 클라이언트 코드의 변경 없이 기능을 확장하고 쉽게 부품을 교체하듯이 개발 가능하다.
  • 이상적으로는 모든 설계에 인터페이스를 부여해야하나, 인터페이스에는 추상화라는 비용이 발생하기에 기능을 확장할 가능성이 없다면 구체 클래스를 직접 사용하고, 필요할 때 리팩터링해서 인터페이스를 도입하는 것도 방법이다.

0207

스프링 핵심 원리 이해

순수 자바만으로 프로젝트를 진행할 경우

  • 요구사항 중에서 어떤 저장소를 사용할 지, 또는 서비스가 미확정일 상황이 생길 수도 있다.
    -> 객체 지향적인 설계 방법을 통해서 인터페이스를 만들고 구현체를 언제든지 갈아끼울 수 있도록 설계하면 된다.
  • 크게 도메인, 서비스, 리포지토리 영역으로 구분된다.

문제점

  • 다형성만으로는 다른 저장소로 변경할 때 OCP 원칙을 준수하지 못하고, DIP를 지키지 못하고 있다.
  • 의존관계가 인터페이스 뿐만 아니라 구현까지 의존하는 문제점이 있다.

JUnit

  • 애플리케이션 로직으로 테스트 하는 것은 좋은 방법이 아니다. 스프링이 지원하는 JUint 테스트를 사용하자
  • Test 밑에 패키지로 구분하여 작성하고, 실행할 메소드 위에 @Test어노테이션을 붙여서 사용한다

태그:

카테고리:

업데이트:

참고