Bootstrap에서 bossGroup과 workerGroup을 받는다. 둘다 eventLoop이고 자체 selector를 가지고 있다. bossGroup은

BootStrap

네트워크 레이어를 구성하는 컨테이너. bossGroup과 workerGroup을 받는다. 생성자가 빌더패턴으로 되어있음

EventLoop

• NioEventLoop = socketChannel + selector

작동순서

• BossNioEventLoop에서 accept event, client와 커넥션 맺기 -> socketChannel 생성 -> socketChannel이랑 selector를 nioEventLooop에다가 등록하기. -> runAllTask
• worker NioEventLoop 스레드에서 socketChannel에서 event를 poll해와서 selector에다가 등록 -> 커넥션이 맺어지면 read write 기능 처리 -> runAllTasks

등록 순서

channel -> selector -> eventLoop

질문

• eventLoop는 왜 group별로 나누어져있는가? 여러 개의 eventLoop를 묶은 이유?

• nioEventLoop는 selector를 가지고 있고, selector에다가 socketChannel을 등록한다고 하는데 대체 socketChannel은 어디있는가?

selector

IO multiplexing에 사용

• IO multiplexing이란? 가장 자주 쓰이는 모델로, 싱글 스레드에서 listen과 블록을 여러 리소스들에 대해 동시에 진행한다 (polling -cpu 자원 낭비- 또는 멀티스레딩을 한다는 의미는 아님) 그리고 하나라도 자원이 준비되면 리턴한다.

• netty에서는 selector도 선택 가능 java 시스템변수로 지정 가능 selector 커스텀을 고민해볼 수도 있을까? 디폴트는 KQueueSelectorImpl ( for mac os)

코드 보고

NioEventLoopGroup

EventExecutor은 interface인데??

필요한 이유

카프카와 다른 시스템을 연결을 더 편리하게 하기 위해서이다. 예를 들어서 카프카 커넥트가 없다면 실패한 데이터를 추적한다거나, 데이터 분산처리, 작업을 배포하는 등의 작업을 직접 구현하여야 한다.

스프링 부트 vs 스프링 MVC

• 스프링 부트
  • 내장 톰캣
  • 자동 환경 구성: 트랜잭션 등 자주 사용하는 몇몇 라이브러리들을 자동적으로 설정해줌. 미리 구성된 스타터 패키지 제공

http://dveamer.github.io/backend/SpringBootAutoConfiguration.html

빈

빈이란?

빈 스코프

필터 vs 인터셉터

필터

• dispatcherServlet 전에 실행
• 예외가 발생하면 was단에서 처리를 해 주어야 ex. 에러 페이지 만들기

인터셉터

• dispatcherServlet후에 실행
• 후에 실행되므로, 필터보다 더 많은 정보(httpServletResponse/Request, 실행될 컨트롤러, 발생한 예외 등)을 전달받을 수 있음
• 예외가 발생하면 스프링 단의 예외처리 방법을 사용할 수 있음

코틀린

코틀린 특징

• 엄격한 null check
• 함수형, 객체지향 프로그래밍 모두 가능
• 기본적으로 immutable이어서 스레드 세이프함
• data 클래스: equals, hashcode, tostring, getter/setter 자동생성으로 롬복기능 일부 대신가능

프로그래밍 패러다임

명령형 프로그래밍

• 알고리즘을 명시
• 데이터들이 mutable함

  선언형 프로그래밍

• 알고리즘이 아닌 목표를 명시
• 데이터 중심적으로, 데이터를 변경하면서 프로그램을 진행하지않으므로 데이터들이 immutable함
• 외부 상태를 변경하지 않도록 인자가 같으면 언제나 같은 값을 반환하는 순수함수 사용
• 매개변수 또는 반환값으로 함수를 사용하는 고차함수를 사용(순수함수들의 집합으로 로직을 만들 수 있음)
• 전달되는 그 함수를 람다라고 함. 람다는 일급함수.

기본 내부구조

ORM이란?

• 데이터베이스와 자바 간 패러다임의 불일치를 해결하기 위한 도구. 개발자들이 비즈니스 로직에 집중할 수 있게 도와준다.
• 패러다임 불일치 해결
  • 반복되는 SQL 자동 생성
  • 자바에서의 상속을 데이터베이스와 매핑해서 객체지향적인 구조를 유지할 수 있게 도와줌

JPA의 장점?

• 패러다임의 불일치 해결
• 연관된 객체 탐색을 보다 간편하게 해줌
• 동등성 관리에 도움(근데 캐시와 프록시가 끼어드니 더 복잡하게 만드는 것 같아서 참조보다는 값을 통한 비교가 나을 수도 있음)
• 1차 캐시(영속성 컨텍스트)를 통한 도움
  • 내부적인 트랜잭션 관리 가능
  • 데이터베이스에 다녀오지 않아도 이미 영속성 컨텍스트에서 가지고 있는 데이터는 곧바로 가져올 수 있음

그래도 Mybatis를 사용하는 이유?

• 지연 로딩같은게 JPA의 장점일 수 있는데, 사실 사용할 객체라면 한번에 join으로 로딩해오는 것이 더 빠를 수 있음
• 어쩌피 현업에서 매우 단순한 쿼리는 잘 사용하지 않아서 성능도 고려하면 대부분의 쿼리는 개발자가 직접 생성해야 함
• 제대로 이해하지 못하고 사용하면 추상화되어있기 때문에 문제를 파악하기 어려움 ex)N+1문제

그래도 JPA가...

• mybatis에서 리턴받은 데이터베이스 오브젝트를 일일히 xml을 통해 자바의 객체와 매핑하는 것이 너무 불편; 패러다임의 불일치 극복 비용이 너무 많이 든다..

엔티티 매니저

• 엔티티와 관련된 모든 일을 처리(CRUD).
• 서버 요청당 하나일 수도(OSIV), 트랜잭션당 하나일 수도 있고 다양함.
• 가장 근본적인 원칙은 앤티티 매니저 팩토리는 스레드 세이프하지만 엔티티 메니저는 스레드 간에 공유가 안됨

영속 컨텍스트

• 1차 캐시 관리
• 내부에 있는 엔티티들은 모두 식별자를 가지고 있음 -> 따라서 Identity전략(mysql에서 사용)트랜잭션에서 write을 할 경우, 식별자를 알아야지 영속 컨텍스트에 넣을 수 있으므로 쓰기 지연이 발생하지 않음

엔티티의 생명주기

• 비영속: 순수한 자바 객체 상태
• 영속: 영속성 컨텍스트에 들어간 자바 객체.
  • 객체의 변경이 추적되어 자동적으로 데이터베이스에 반영된다.
  • 1차 캐시
  • 동일성 보장
  • 트랜잭션 쓰기 지연: flush전에는 데이터베이스에 직접 락을 걸지 않으므로 장점
  • 지연 로딩
• 준영속: 트랜잭션의 종료 또는 명시적인 영속성 컨텍스트 종료 등으로 영속성이 끊어진 상태. 거의 비영속 상태인데 차이는 식별자 값을 가진 것
• 삭제

관련 어노테이션

@PersistenceContext

• 순수 자바 어플리케이션과는 달리, 스프링에서는 EntityManager를 알아서 관리해주기에, 직접 EntityManagerFactory에서 주입받지 않더라도 주입받을 수 있음

@Repository

• 해당 클래스가 빈으로 등록
• JPA전용 에러가 발생하였을 때 추상화된 스프링의 DB에러로 한번 더 감싸서 나옴

객체의 연관관계

다대일 양방향

• member * - 1 team일 경우
• member가 foreign key를 관리할 수 있도록 설정하는 것이 편리. -> @ManyToOne
• team는 member의 외래키를 이용해서 List< member >를 생성하는 것이므로, 연관관계의 실제 주인인 member의 team속성을 넣어줌-> @ManyToOne(mappedBy="team")
  • 왜넣어주지? 싶었는데 List< member >이 많을 경우 ex) 학교 팀 멤버들, 동네 팀 멤버들... 이렇게 있을 때 구분해주기 위해서인듯
• 주의사항
  • 한쪽에만 데이터를 넣거나 삭제하면 다른 쪽에는 반영되지 않기 때문에, 양쪽에 넣어주는 함수 만들어 사용하면 편함(단, 영속성 전이를 사용하면 양쪽에 반영할 수 있음)
  • 순환참조

상속관계

• 부모, 자식들을 각자 다른 테이블로 만듬

  • 장
    • 테이블이 정규화됨
    • 효율적인 데이터 사용
  • 단
    • 많은 조인이 들어감
    • insert할때 부모, 자식 두번 들어감

• 부모, 자식에서 필요한 칼럼들을 모아서 하나의 테이블로 만듬

  • 장
    • 성능을 높일 수 있음
    • 조회 쿼리 단순
  • 단
    • 칼럼들이 nullable해짐
    • 저장공간 낭비

• 부모에서 필요한 칼럼들을 모두 자식 테이블에 넣음

  • 장
    • 메모리 공간 절약 + 부모 테이블에 조인할 필요성 없음
  • 단
    • 자식들을 한꺼번에 모아서 처리하기 불편함

식별관계 vs 비식별관계

• 식별관계: 부모 테이블의 기본 키를 받아서 자식 테이블의 기본키 + 외래키로 사용하는 방식
• 비식별관계: 부모 테이블의 기본 키를 자식 키에서 외래키로 사용하는 것

로딩

지연 로딩

• 한번에 모든 데이터들을 가져오는 것은 매우 비효율적이어서 정말 사용할 때 가져오는 방식
• JPA에서는 바이트 코드를 로딩할때 조작하는 로드타임 위빙 방식과 프록시 방식을 사용

프록시 방식

• 객체를 getReference로 조회하면 엔티티 그대로의 객체가 오는 것이 아니라, 프록시로 한번 더 감싸진 객체가 온다. (영속성 컨텍스트에 존재하면 이미 로딩되었다는 것이므로 불필요하게 프록시로 감싸져있는게 아닌 실제 엔티티를 가져옴)
• getReference로 얻은 프록시 객체는 식별자를 가지고 있기에 AcessType이 프로퍼티인 경우에는 getId를 해도 엔티티가 초기화되지 않음(?어떻게.....? Mysql은 디비에 넣어야지 식별자를 알 수 있을텐데... 임시식별자인가?)
• 실제 데이터를 얻기 위해 get메서드를 사용할 때 초기화를 진행한다.
• 영속성 컨텍스트의 범위에서 벗어나 있는 경우(ex 컨트롤러단, 영속성 컨텍스트 종료)에 해당 속성에 접근하려고 하면 LazyInitializationException이 뜬다.

Spring Data JPA

사용 이유

• 별다른 구현 클래스 없이 인터페이스만 만들어놓으면 네이밍 규칙만 맞추면 자동으로 쿼리를 생성해준다 (JpaRepository를 상속받아야 함)
• 이미 몇가지 findAll같은 인터페이스는 이미 JpaRepository에 들어있음

트랜잭션

영속성 컨텍스트

• 트랜잭션이 같으면 같은 영속성 컨텍스트를 사용

준영속 상태의 지연 로딩 문제

컨트롤러에서 추가적으로 엔티티를 초기화할 필요가 있을수도 있음. 하지만 컨트롤러는 트랜잭션의 범위를 이미 넘어가서 엔티티가 비영속 상태이고, 더이상 초기화가 불가능해짐.

• 해결방법1: 페치 전략을 즉시로딩으로 수정
  • 단: N+1문제가 발생, 불필요한 엔티티를 로딩해둠
• 해결방법2: OSIV를 사용
  • 이전 OSIV: 필터 또는 인터셉터에서 트랜잭션을 시작해 요청당 하나의 영속성 컨텍스트를 사용 -> 컨트롤러에서 뷰에 보여지기 위해 임시로 엔티티의 데이터를 수정하면, 영속성 컨텍스트 내부에 있으므로 결과적으로 요청을 반환할 때 DB에 반영되는 문제
    • 해결책: 엔티티를 읽기 전용으로 전달(getter만 있는 인터페이스 타입으로 전달. 매번 인터페이스를 작성해야 한다는 불편함), DTO로 전달, wrapper로 전달 다 비슷한 단점
  • 현재 OSIV: 필터 또는 인터셉터에서 영속성 컨텍스트를 만들어 영속성 컨텍스트는 요청 전체로 유지를 하되, 트랜잭션은 서비스 계층만으로 국한시킴. -> 서비스 호출이 끝나고 컨트롤러에서 데이터를 수정하여도, flush는 이미 하였으니 디비에는 반영되지 않을 것. flush를 명시적으로 호출하여도 트랜잭션의 범위 밖이라서 데이터 변경 불가 에러 발생(그런가보다..) 하지만 service -> 컨트롤러에서 수정 -> service하면 결국 flush하니 디비에 반영되는디...? -> 그러지 마라....

롤백 문제

트랜잭션이 롤백되어도, 영속성 상태의 객체는 이미 수정되어서 남아있음. 따라서 명시적으로 em.clear같이 초기화를 해줘야 함 -> 그런데 스프링에서는 내부적으로 롤백발생하면 알아서 초기화해줌

추가적인 문제들

엔티티 동등성

• 영속성 컨텍스트가 같으면 같은 엔티티는 같은 참조를 가짐
• 반면 영속성 컨텍스트가 다를 때는 엔티티의 동일성 비교(==)는 실패하므로, 되도록이면 미스하지 않도록 동등성 비교(equals)쓰는게 좋음

프록시 객체 동등성

• getReference하고 find하면? -> 영속성 컨텍스트에서는 find에다가 이미 찾아놓은 프록시 객체 돌려줌
• find -> getReferenct하면? -> 영속성 컨텍스트에서는 getReference에다가 이미 로딩해놓은 엔티티 객체 돌려줌
• 동등성 지켜짐
• 심화문제있는데 나중에 657 이해해보자

성능 최적화

N+1문제

지연 로딩으로 인해 객체들을 찾아오고, 가지고있는 외부참조 속성들을 하나씩 초기화하게 되면 요청이 매 객체마다 날라가는 문제 발생

락

낙관적 락

• 트랜잭션 대부분이 충돌이 발생하지 않는다고 가정
• JPA가 제공하는 버전 관리 기능 이용
• 동시에 두 데이터를 트랜잭션에서 변경할 때, 최초 커밋만 인정하도록 구현
• Version사용: 트랜잭션이 데이터를 변경하거나, 심지어는 조회만 했을 때(경우에 따라 다르게 설정가능) 버전을 하나씩 높임. 칼럼으로 하나 둬서 JPA가 관리. 만약 커밋을 할 때 내가 가지고 있는 버전과 다르면 다른 트랜잭션에서 이미 접근했다는 의미이므로 에러를 발생시키고 반영하지 않음.
  • NONE: 데이터 변경시 버전 높여서 두번의 갱신으로 인해 데이터가 유실되는 것을 방지
  • OPTIMISTIC: 조회시 버전을 높여서 다른 트랜잭션들의 non repeatable read를 방지

비관적 락

• 트랜잭션의 충돌이 발생한다고 가정하고 우선 락을 검
• 데이터베이스가 제공하는 락 기능 사용(ex. for update)

2차 캐시

• 2차 캐시를 추가로 둘 수 있음.
• 1차 캐시에서 없으면 2차 캐시를 한번 더 찾아서 네트워크 비용을 줄일 수 있도록 함
• 동시성을 극대화하기 위해 객체를 그대로 반환하지 않고 복사본을 반환

기능

• 트랜잭션 추상화

  • 서비스의 종류나 환경이 변화되더라도 트랜잭션을 사용하는 코드는 그대로 유지 가능

• 트랜잭션 동기화

트랜잭션 경계설정방법

• PlatformTransactionManager의 구현체들을 사용
• getTransaction -> commit or rollback 메서드 사용

1. 코드를 이용한 트랜잭션 경계설정
2. 선언적 트랜잭션 경계설정: 데코레이터를 이용한 트랜잭션 프록시 빈 사용
   • @Transactional

@Transactional 동작방법

프록시 기반으로 다이나믹 프록시나 CGLib를 통해서 구현되거나, 타깃 오브젝트를 직접 조작하는 방식의 AspectJ방식이 있습니다. 스프링 boot는 디폴트로 CGLib를 사용

• 다이나믹 프록시는 인터페이스에 적용하는 프록시이기 때문에 인터페이스가 필요
• CGLib는 클래스를 상속해서 프록시를 만들기 때문에 final 클래스는 불가
• AspectJ는 프록시를 타깃 오브젝트 앞에 두지 않고, 타깃 오브젝트 자체를 직접 조작

http://wonwoo.ml/index.php/post/1708

트랜잭션 속성

트랜잭션 전파

새로운 트랜잭션이 시작될 경우, 이것을 기존의 트랜잭션에 참여시키는 방법을 결정

• required: 디폴트. 기존의 트랜잭션이 있으면 참여하고 없으면 새로 시작
• requires_new: 매번 새로운 트랜잭션
• nested: 부모의 트랜잭션에 참여하지만, 자신이 에러가 발생할 경우에는 부모에 영향을 끼치지 않는다. 로그작업같은데 쓰임. 내부적으로 savepoint를 사용

트랜잭션 격리수준

• read_uncommitted: dirty read(트랜잭션 작업이 완료되지 않았는데도 다른 트랜잭션에서 볼 수 있는 현상) 발생. 다른 트랜잭션의 커밋하지 않은 데이터들을 읽을 수 있음
• read_committed: 다른 트랜잭션의 커밋한 데이터를 읽을 수 있음. 다시 읽었을 때 데이터가 달라질 수 있는 문제 발생
• repeatable_read: 하나의 트랜잭션이 일관적인 데이터를 볼 수 있도록 함. 단, 다른 트랜잭션에서의 삽입의 경우에는 새로운 데이터가 추가될 수 있음.
• serializable: 읽기에는 shared_lock, 쓰기에는 exclusive_lock을 걸어서 극도의 일관성을 보장.

그 외

• timeout
• read_only
• rollback_for

오브젝트와 RDB 사이에 존재하는 패러다임의 불일치 때문에 요구되는 불편한 작업들(sql 작성, 자바 객체에서의 상속 - DB에서는 외래키로, 다형성, 레퍼런스, 오브젝트 합성)을 대신 해결해준다. DB와 자바 객체의 자동 매핑, SQL자동생성 등이 존재.

JPA vs Mybatis

• mybatis
  • 단
    • SQL을 직접 작성하고, 결과를 따로 xml에 매핑해서 자바 객체에 담아주는 작업이 번거롭다.
      • 장

JDBC -> Mybatis -> JPA

• mybatis

  • 자바오브젝트만을 이용해 데이터 로직 작성 가능(이전에는 ResultSet으로 담아옴)
  • SQL을 별도의 파일로 분리 가능

• JPA

  • 데이터베이스의 오프젝트와 자바의 객체 간 매핑을 자동적으로 해줌
  • 기본적인 SQL을 작성할 필요가 없음

JPA

EntityManager

• DAO에서 주입받아서 사용해야 함
• @PersistenceContext EntityManager em;
• 트랜잭션마다 한번 만들어지고, 종료되면 함께 제거되어야하는데 어떻게 이 코드로? 이 코드는 마치 DAO에서 한번 주입받고 계속 쓰는 것 같음
• => 저 EntityManager은 실제 EntityManager이 아니라 프록시임. 각 트랜잭션마다 다른 EntityManager을 보장

바이트코드 향상 기법

• 바이트코드를 직접 조작해서 지연 로딩, 엔티티 값 변화 추적, 최적화와 그룹 페칭 등의 고급 기능 적용 가능
• 방법
  • 바이트 코드를 빌드 중에 변경: JPA가 제공하는 바이트코드 컴파일러가 필요하다는 단점이 있음
  • 바이트 코드를 로딩하면서 다이내믹하게 바이트코드를 변경해 기능 추가(로드타임 위빙)
  • 지연로딩을 위해 프록시를 사용

Hibernate

• JPA의 구현체
• JPA의 EntityMangerFactory처럼 핵심 역할을 하는 SessionFactory존재
• TransactionManager존재

• 스프링은 이전에 프레임워크와 의존성이 매우 높았던 EJB대신 POJO객체를 쓰는 것을 강조한다.
• POJO란 프레임워크에 독립적인 객체를 의미한다.
• IOC컨테이너, 즉 application context에서 beanFactory 인터페이스들을 확장해 bean들의 라이프사이클을 관리한다.

bean의 메타정보

• 빈 아이디: 빈 오브젝트를 구분할 수 있는 식별자
• 클래스 or 클래스 이름: 빈으로 만들 POJO클래스 또는 서비스 클래스 정보
• 스코프: 빈의 생성 방식과 존재 범위
• 프로퍼티 값 또는 참조: DI에 사용할 프로퍼티 이름과 값 또는 참조하는 빈의 이름
• 생성자 파라미터 값 또는 참조: DI에 사용할 생성자 파라미터 이름과 값 또는 참조할 빈의 이름
• 지연된 로딩 여부, 우선 빈 여부, autowiring여부, 부모 빈 정보, 빈팩토리 이름 등

bean scope란?

• singleton: 한번만 생성해서 캐시해두고 계속해서 사용(디폴트)
  • 상태가 없을 때
  • 이뮤터블 할 때
  • 상태가 있어도 생성하는 비용이 매우 클 때
• prototype: 사용할때마다 계속 생성
  • 뮤터블해서 동기화 비용을 생각할 바에는 객체를 새로 만들 때
• request: 한 http request안에는 하나의 객체만 존재
• session: 한 http session안에는 하나의 객체만 존재
• global session: 한 global session안에는 하나의 객체만 존재

singleton vs prototype

• 싱글톤
  • ioc컨테이너가 빈의 초기화 및 라이프사이클 관리
• prototype
  • ioc컨테이너는 빈을 초기화하고 di를 해주지만, 거기서부터는 di받은 빈이 담당한다. 즉, di받은 빈이 제거되면 그때 해당 빈도 제거됨
  • 사용자의 요청별로 필요한 오브젝트(ex DTO)를 new로 안만들고 ioc에서 DL받을 필요가 있을 때 사용 ex) DTO 내부에서 DB에 접근할 필요가 있어서 DAO를 주입받아야 할 때
  • 왜 DI를 안하고 DL을?: DI를 할 경우에는 컨트롤러에서 DTO를 di받을텐데, 이렇게 하면 컨트롤러의 빈스코프가 싱글톤이기 때문에 해당 DTO의 빈스코프가 프로토타입이어도 요청마다 제거되지 않음. 따라서 컨트롤러에 들어와서 지역변수에다가 DL을 하면 요청이 끝나면 제거됨.

다른 요청 스코프, 세션 스코프들은 왜 DL?

• DI로 할 경우에는 맨처음에 객체를 초기화할 때, 에러가 발생할 것<- 요청 스코프는 요청이 들어오면 객체를 생성하기 때문. 따라서 나중에 주입할 수 있는 DL로 찾아오는게 옳다.

요청 스코프와 프로토타입의 차이

• 그러면 매 요청마다 새로 생성되니 같은 것 아닌가?
• ㄴㄴ 보통 평범하게 사용하면 매 요청마다 새로 생성하겠지만, getBean을 여러번 하면 요청 스코프는 요청 안에서는 매번 똑같은 객체를 얻을 수 있지만, 프로토타입의 경우에는 매번 다른 객체를 얻음

수정자 주입, 생성자 주입 application Context 두개

DL방식

• ServiceLocatorFactoryBean, 메소드 주입 등등..
• @Inject Provider< T >사용하는 방식이 제일 많이 쓰임

세션 스코프 동작방식

스코프 프록시 오브젝트 사용 - 어떤 오브젝트를 가져올지는 알아서 추상화가 됨

bean을 가져오는 순서

• 빈의 메타 정보를 기록해 둔 beanDefinition을 등록 applicaionContext에 등록
• applicaionContext내부에서 빈을 생성
• applicationContext에서 빈을 가져와서 사용

WebApplicaionContext

• ApplicationContext구현체중 WebApplicationContext가 웹 서비스에서 가장 편하게 사용 가능
• main메소드 역할을 하는 서블릿을 만들어두고, 어플리케이션 컨텍스트를 생성한 뒤, 요청이 서블릿으로 들어올 때마다 getBean으로 빈을 가져와 정해진 메소드를 실행하는 방식이었는데(스프링의 덜 추상화된 api를 사용하니 프레임워크에 종속적으로 됨), webApplicationContext를 사용하면 DispatcherServlet이 중간 역할을 대신해준다. 요청이 들어오면 기존에 생성한 어플리케이션 컨텍스트에서 빈을 찾아와 이를 실행시켜주는 역할
• 이 DispatcherServlet가 들어온 모든 요청에 대해 filter를 처리하고 알맞은 핸들러에 요청을 전달하기 때문에 프론트 컨트롤러라고도 함

bean 스캔 방식

• 스테레오타입 어노테이션이 붙어 있을 경우 빈으로 인식: 클래스에 붙어서 해당 클래스가 컴포넌트 스캐닝의 대상이고 스프링을 통해 관리될 것이라고 명시하는 어노테이션

bean등록 방법

• configuration + bean: bean이 싱글톤일 경우 싱글톤으로 동작
• bean: 매 요청마다 새로운 객체를 리턴
• component: 클래스에 붙이는 스테리오타입 어노테이션

autowired

방식

• 생성자:
  • 장
    • 수정자 메소드가 많아질 일이 없다
    • 순환 참조를 미리 알 수 있다.
  • 단
    • 일부 프로퍼티는 쪽 DI하지 않고 선택적으로 DI할 수 있도록 하지 못한다(아니 할 수 있잖아????)
• 수정자
• 필드

  관련 anotation

• resource: 빈의 이름과 타입으로 찾음
• autowired: 빈의 이름과 타입으로 찾음
  • resource와의 차이: 생성자에도 부여 가능
• qualifier: 빈에게 한정자 값을 주고 이 한정자를 가진 빈을 autowired할 수 있게 한다.
• value: 해당되는 값을 넣어줌

컨테이너 위치

WebApplication 레벨에 컨테이너 존재

• 프론트 컨트롤러 서블릿의 어플리케이션 컨텍스트를 자식으로, 웹 어플리케이션에 어플리케이션 컨텍스트를 부모로 두는 구조
• 하나로 합쳐도 되지만, 스프링을 사용하지 않는 기술들은 서블릿을 거쳐갈 필요가 없기에 곧바로 루트 어플리케이션 컨텍스트에 접근하라고 둠

주입 방식

생성자 주입

• 어플리케이션을 실행하면 객체를 생성하기 위해 DI를 받는데, 여기서 순환참조를 확인할 수 있음.

  필드 주입, 새터 주입

• 객체를 메모리에 올린 다음에 DI를 하므로, 어플리케이션을 실행해도 에러를 발견할 수 없음
• 필드를 final로 지정할 수 없음

https://coding-start.tistory.com/250

MVC패턴이란?

모델, 뷰 컨트롤러로 이뤄진 패턴으로, 두가지 구현 방식이 존재

• 모델이 뷰를 옵저버로 관리

spring mvc vs spring boot

• 생성자에 이름을 가질 수 있음
• 인스턴스를 새로 생성하지 않아도 됨
  • immutable이기 때문에 객체를 만들어놓고(캐싱해놓고) 재활용 가능
    • 싱글턴

  • 싱글턴 방식

• 인스턴스를 하나만 만들고 재활용하는 방식

중첩 클래스

종류

• 정적 멤버 클래스: 바깥 클래스의 private멤버에도 접근할 수 있음(일반 클래스와 비교)
• inner class
  • 비정적 멤버 클래스
  • 익명 클래스
  • 지역 클래스

• 객체지향적인 프로그래밍을 위해서
• aop, ioc, di, psa를 사용하여 훨씬 간단한 프로그래밍 가능

어떻게 객체지향적인 프로그래밍을?

• aop는 분산된 책임을 한 곳에 집중시키므로 srp원칙을 지킬 수 있음
• ioc는 객체의 생성과 라이프사이클 관리를 프레임워크에 맡기는 방식이므로, 의존성을 줄일 수 있음
• psa를 이용해서는 환경에 구애받지 않는 프로그래밍을 할 수 있으므로 의존성을 줄일 수 있다.

AOP

AOP란?

분산되어있는 횡단관심사들을 핵심로직들과 분리해 한곳에 모아서 개발하는 기법

어떻게 구현하는가?

프록시 기반으로 다이나믹 프록시나 CGLib를 통해서 구현되거나, 타깃 오브젝트를 직접 조작하는 방식의 AspectJ방식이 있습니다. Spring AOP에서는 다이나믹 프록시나 cglib사용

• 다이나믹 프록시는 인터페이스에 적용하는 프록시이기 때문에 인터페이스가 필요
• CGLib는 클래스를 상속해서 프록시를 만들기 때문에 final 클래스는 불가. 런타임 위빙, 하지만 나중에 캐싱해서 사용하기는 함
• AspectJ는 프록시를 타깃 오브젝트 앞에 두지 않고, 타깃 오브젝트 자체를 직접 조작. 클래스 or 클래스로드 타임 위빙을 하기 때문에 좀더 빠르다.

IOC

IOC란?

• 프로그램의 흐름을 프레임워크에 위임하는 방식
• 구체적으로 이야기하면 객체의 라이프사이클을 프레임워크에서 관리
• 방법으로 DI와 DL을 사용함

DI란?

• 객체를 주입받는 방식
• DI사용 이유: 의존 객체를 매번 직접 생성하면 메모리 낭비도 있고, 객체 수정을 하면 산탄총 수술을 해야 함
• 테스트에도 편리(테스트시에는 테스트를 위한 클래스를 주입해줄수도 있음)
• setter, 생성자, 필드 주입 방식

어느 주입 방식이 가장 좋은가?

• 생성자 주입 방식
• immutable한 객체를 만들 수 있고, 객체 생성시점에서 순환참조 여부를 알 수 있다. (왜? -> 컨테이너가 빈을 생성하는 시점에 객체생성을하는데, 그때 순환참조가 생기기 때문. 필드주입 같은 경우에는 객체생성시점에 필드주입을 하지는 않는듯.)

https://yaboong.github.io/spring/2019/08/29/why-field-injection-is-bad/

DL이란?

IOC컨테이너를 참조해 얻고자하는 객체를 검색하는 것

PSA

PSA란?

• 환경에 구애받지 않고 프로그래밍을 할 수 있는 추상화 기법
• 예: PlatformTransactionManager은 구현체가 변경되더라도 동일한 인터페이스로 프로그래밍 가능

final, static

final

객체마다 하나씩 가지고, 값을 바꿀 수 없음

static final

클래스에 하나뿐이고, 값을 바꿀 수 없는 엄연한 상수

static 변수는 어디에 올라가는가?

• method area에 정적으로 클래스 정보를 올릴 때 올라감
• heap 영역에 동적으로 생성되는 객체들은 GC의 영향을 받지만, method area에 들어간 클래스 정보들은 프로그램이 끝날때까지 계속 유지되므로 남발하면 안됨

JPA

JPA란?

자바 어플리케이션에서 관계형 데이터베이스를 사용하는 방식을 정의한 인터페이스

Hibernate란?

JPA의 구현체

Spring Data JPA란?

• JPA를 쓰기 편하게 만들어놓은 모듈
• Repository라는 추상화 인터페이스가 핵심
• Repository에 적합하게 함수명을 만들면 자동으로 쿼리를 만들어준다.

ORM

• 객체와 관계형 데이터를 자동으로 매핑시키는 것
• Sequelize, JPA 등 써봄
• 장: 비즈니스 로직에 집중 가능, 추상화로 인해 DB의 구현에 덜 의지하게 됨
• 단: 프로시저가 많은 경우에는 도입이 까다로움

스프링 트랜잭션

갑자기 undefined에서 값을 불러오려고 한다는 것이다.

에러난 부분의 코드는 아래와 같다.

if (this._android && this._android <= 2.1) {
            var factor = 1 / window.devicePixelRatio;
            var drawImage = CanvasRenderingContext2D.prototype.drawImage;
            CanvasRenderingContext2D.prototype.drawImage = function (image, sx, sy, sw, sh, dx, dy, dw, dh) {
                if (("nodeName" in image) && /img/i.test(image.nodeName)) {
                    for (var i = arguments.length - 1; i >= 1; i--) {
                        arguments[i] = arguments[i] * factor;
                    }
                } else if (typeof dw == "undefined") {
                    arguments[1] *= factor;
                    arguments[2] *= factor;
                    arguments[3] *= factor;
                    arguments[4] *= factor;
                }

                drawImage.apply(this, arguments);
            };
        }

왜 갑자기 이전에는 window에 잘 바인딩되던 this가 이번에는 undefined로 바인딩 되어 에러가 발생한 것이다.

자세히 알아보니 모듈 방식은 strict모드를 사용한다는 것을 알게 되었고 strict모드에서는 전역에서 this가 window로 바인딩되지 않는다는 것을 깨달았다.

즉, 순서대로 생각하면 이 new QRCode()를 실행하는 곳은 모듈이었기 때문에 this는 undefined로 바인딩된다. 여기서 생성자를 호출해 QRCode 인스턴스를 생성했다면, 그 인스턴스는 호출한 곳의 this에 바인딩되고, 그 인스턴스의 this도 undefined가 된다.

  const printCode = (url) => {
    const qrCode = new QRCode("qrcode", qrOption);

    qrCode.makeCode(url);
};

그러면 해결책은

1. 인스턴스의 this를 window로 바인딩
2. strict모드를 취소
3. 코드를 수정

이렇게 세가지 방법이 있을 수 있다. 하지만 1번의 경우, new를 통해 객체의 인스턴스를 생성하는 작업에 call함수를 통해 this를 바인딩하는 것은 불가능했다. 또한 2번도 찾아본 결과 불가능했다. 결국 this에러가 발생하는 코드를 window로 직접 수정해보기로 하였고, 일단 한 줄만 수정해서 해결이 되었다.

하지만 현재 상황에서만 잘 동작하지, 다른 상황에서는 어떻게 동작할지 모르므로 코드를 직접 읽고 이해해서 고치거나, 모듈 방식이 아니라 script방식을 그대로 사용하는 것이 좋을 것 같다.

객체지향 설계 방법

• 상태를 분할의 중심축으로 삼기
• 책임을 분할의 중심축으로 삼기 두가지 방법이 있다. 물론 후자가 더 적합한 방법이다. 객체의 데이터(상태)는 구현에 속한다. 구현을 중심으로 삼으면 인터페이스에 구현의 세부사항이 들어가고, 캡슐화의 원칙이 무너진다. 결과적으로 상태가 변경되면 인터페이스가 변경되고, 인터페이스에 의존하는 모든 객체들이 변경된다.

반대로 책임은 인터페이스에 속하므로, 안정적으로 캡슐화가 가능하고 구현의 파장이 외부로 벗어나지 않는다.

객체지향 평가 방법

객체지향적인 설계인지 평가하는 방법에는 세 가지가 존재한다.

• 캡슐화
• 응집도
• 결합도

캡슐화

캡슐화는 품질의 가장 중요한 척도로서, 응집도와 결합도에도 영향을 끼친다. 객체의 상태와 행동을 객체 안에 모으는 것을 캡슐화라고 한다. 변경될 가능성이 높은 구현은 내부에 두고, 안정적인 인터페이스를 통해 외부와 통신하는 것을 말한다.

응집도, 결합도

응집도란 모듈에 포함된 내부 요소들이 연관되어있는 정도를 나타낸다. 구체적으로 말하면, 변경이 발생할 때 모듈 내부 전체가 함께 변경된다면 응집도가 높은 것이다.

결합도

결합도란 다른 모듈에 대해 얼마나 많은 지식을 가지고 있는지를 나타낸다. 한 모듈이 변경될 때 외부의 다른 모듈이 변경된다면 결합도가 높은 것이다. 내부를 변경했을 때 외부 모듈에 영향을 끼치는 것 또한 결합도가 높다고 할 수 있다. 반면, 내부를 변경할 때는 외부에 영향을 끼치지 않고, 퍼블릭 인터페이스를 바꿔야지만 다른 모듈에 영향을 끼치는 경우를 결합도가 높다고 한다.

객체지향의 목적

• 책임을 분산시킨다.
• 응집도를 높이고 결합도를 낮춘다.
• 결합도를 낮추는 방법으로 캡슐화, 책임분산, 데이터와 프로세스의 통합이 있다.

결합도

객체 사이의 의존성이 과한 경우 결합도(coupling)이 높다고 말한다. 의존성이 있을 경우, 어떤 객체가 변경될 때 그 객체에게 의존하는 다른 객체도 함께 변경될 수 있다는 사실이 내포되어 있다.

캡슐화

결합도를 낮추는 방법으로(객체의 자율성을 높이는 방식으로) 캡슐화가 있다. 객체 내부에 세부적인 사항을 감추는 것을 캡슐화라고 한다. 즉, 외부에 존재하는 프로세스를 내부로 감추는 것이다. 간단한 예시로 티켓을 판매하는 프로세스를 들 수 있다. Theather에서 필드로 가지는 TicketSeller를 통해 티켓을 꺼내고, Audience의 돈을 꺼낼 수도 있다. 하지만 이러한 일련의 과정을 TicketSeller의 sellTo 메서드에 넣어서 캡슐화를 할 수 있다. 이러면 Theather은 TicketSeller의 sellTo 메서드만 호출하면 되지, Audience가 무슨 함수를 가지고 있는지, TicketSeller은 어떤 방식으로 Ticket을 판매하는지 몰라도 된다. 이를 Theather은 오직 TicketSeller의 인터페이스에만 의존한다고 한다. 이처럼 객체를 인터페이스와 구현(implementation)으로 나누고 인터페이스만을 공개하는 것은 객체 사이의 결합도를 낮춘다.

데이터와 프로세스

데이터: 객체 안의 필드 프로세스: 데이터를 다루는 행위

예를 들어서 티켓을 사는 것은 프로세스고, 티켓은 데이터이다. 티켓 구매 프로세스를 객체 바깥에서 한다면, 이는 책임을 다른 객체에게 넘기는 것이고 결합도가 높아진다.

2. 객체지향 프로그래밍

도메인

도메인이란, 문제를 해결하기 위해 사용자가 프로그램을 사용하는 분야를 뜻한다. 예를 들어 영화를 쉽고 빠르게 예매하려는 문제가 있다. 이를 위해 영화 예매 분야(도메인)을 이용할 수 있다.

도메인의 구조를 정하고, 이와 유사하게 클래스의 구조를 정해야 한다. 그 다음 설계 과정을 거친 뒤 코드를 짜기 시작한다.

필드와 메서드

필드는 private으로, 메서드는 public으로 두어야 한다. 그를 통해 외부에서는 객체의 속성에 직접 접근할 수 없도록 막고, 적절한 public 메서드를 통해서만 내부 상태를 변경할 수 있게 해야 한다. 이처럼 클래스의 내부와 외부를 구분해야 객체의 자율성이 보장된다. 즉, 캡슐화를 넘어서 접근 제어를 통해 내부(구현)과 외부(인터페이스)를 구분해야 객체의 자율성을 지킬 수 있다. 이를 구현 은닉이라고도 한다.

다형성

객체들 사이의 상호작용을 협력이라고 한다. 객체지향에서의 협력은 객체들 사이의 요청과 응답으로 이루어진다. 요청의 방법은 메시지를 보내는 것 뿐이다. 도착한 메시지를 처리하는 방법을 메서드라고 한다. 즉, 객체에게 인터페이스를 통해 메시지를 보내면, 객체 내부에서는 메서드를 선택해서 처리한다. 여기서 어떤 메서드로 처리할지 컴파일 시점이 아니라 실행 시점에 결정하는 것을 동적 바인딩이라고 한다. 이와 같이 메시지와 메서드가 구분되어 있을 때, 다형성이 성립한다. (다형성은 동적 바인딩을 통해 구현된다.)

의존성

어떤 클래스가 다른 클래스에 접근할 수 있는 경로를 가지거나, 해당 클래스의 객체의 메서드를 호출할 경우 두 클래스 사이에 의존성이 존재한다고 말한다. 코드의 의존성과 실행 시점의 의존성은 다를 수 있다. DiscountPolicy라는 추상 클래스가 존재하고, 이 클래스를 상속받는 PercentDiscountPolicy가 있다. 코드 상에서 DiscountPolicy에게 의존할 수 있지만, 실행 시점에는 PercentDiscountPolicy에 의존할 수 있다. 이처럼 코드의 의존성과 실행 시점의 의존성이 다를 경우 확장성은 높아지지만, 코드를 이해하기는 어려워진다.

어떻게 이처럼 시점에 따라 의존성이 다를 수 있을까? 오직 calculateDiscountAmount라는 메시지를 받을 수만 있다면 객체가 어떤 클래스의 인스턴스인지는 상관하지 않기 때문이다. 이렇게 인터페이스에 의존하는 방식을 업캐스팅이라고 한다.

상속과 합성

상속

상속은 코드를 재사용할 수 있다는 장점을 가진다. 하지만 단점이 있다.

• 캡슐화를 위반한다.
• 설계를 유연하지 못하게 한다.

캡슐화를 위반하는 이유는, 상속을 위해서 부모 클래스의 내부 구조를 잘 알고있어야 하기 때문이다. 즉, 부모 클래스의 구현이 자식 클래스에게 노출되기 때문에 캡슐화가 약화된다. 캡슐화가 약화되면 부모 클래스가 변경될 때, 자식 클래스도 변경될 가능성이 높아진다.

설계를 유연하지 못하게 하는 이유는, 컴파일 시점에 어떤 객체가 사용될지 결정되기 때문이다. 따라서 실행 시점에 객체의 종류를 변경하는 것이 불가능하다.

합성

합성은 객체 간에 인터페이스를 통해 정의된 메시지를 통해서만 통신하는 것을 뜻한다. 실제적인 구현은 객체 내부에 담겨지므로 캡슐화를 이룰 수 있고, 인터페이스에만 의존하니 실행 시점에 객체를 변경할 수 있어 설계가 유연해진다.

3. 역할, 책임, 협력

협력

객체들이 애플리케이션의 기능을 구현하기 위해 수행하는 상호작용을 협력이라고 한다. 협력의 유일한 방법은 메시지 전송 뿐이다. 메시지를 수신하면 메서드를 실행해 요청에 응답한다.

협력은 객체의 행동을 결정하고, 행동은 객체의 상태를 결정한다. 예를 들어서 영화 예매라는 협력을 위해 Movie는 요금을 계산하는 행동을 한다. 이 행동을 위해 Movie는 기본 요금인 fee와 할인 정책인 discountPolicy라는 상태를 가진다. 즉, 협력은 객체의 행동과 상태를 결정하는데 필요한 문맥을 제공한다.

책임

협력에 참여하기 위해 객체가 수행하는 행동을 책임이라고 한다. 책임은 객체가 유지해야하는 정보와 수행할 수 있는 행동에 대해 개략적으로 서술한 문장이다. 책임은 메시지보다 개념적으로 크고 추상적이다. 객체에게 얼마나 적절한 책임을 할당하느냐가 설계의 전체적인 품질을 결정한다.

정보 전문가 패턴

책임을 객체에게 나누기 위한 하나의 방법이다. 협력이라는 문맥을 정의하고, 그를 하나의 책임으로 본다. 그 다음 더 작은 책임과 책임을 맡을 수 있는 적절한 정보 전문가를 찾아내가는 방식을 말한다. 이렇게 책임을 찾아나가면서, 인터페이스와 오퍼레이션의 목록을 구할 수 있다. 이러한 책임에 초점을 맞춘 설계 방식을 책임 주도 설계라고 한다.

책임을 할당할 때는 두 가지 요소를 고려해야 한다.

• 메시지가 객체를 결정하게 한다.
  • 최소한의 인터페이스만 가지게 된다.
  • 어떻게가 아니라 무슨 메시지를 처리할지 고려하게 되므로 추상적인 인터페이스를 가질 수 있게 된다.
• 행동이 상태를 결정한다.
  • 객체의 상태를 고민하고 행동을 결정하면, 상태가 외부에 노출되게 되어 캡슐화를 낮춘다.

의문점

정보 전문가 패턴은 객체의 상태(정보)를 고려하고, 책임에 맞는 객체를 선택하는 방법이다. 그렇다면 상태가 객체를 결정하지 메시지가 객체를 결정하는 방법이 아니지 않나?

역할

객체가 어떤 특정한 협력 안에서 수행하는 책임의 집합을 역할이라고 한다. 책임을 통해 객체를 결정할 때, 하나의 책임을 여러 객체들이 수행할 수 있을 경우 이는 역할이 된다. 역할을 구현하는 가장 일반적인 방법은 인터페이스 또는 추상 클래스이다. 이 둘은 책임의 집합을 서술해 놓은 것인데, 추상 클래스는 그 일부를 구현해 둔 것이고 인터페이스는 책임의 집합만을 나열해 둔 것이다.

여러 시나리오를 고려해보고, 협력을 지속적으로 정제해 보면 그 협력들이 거의 유사한 구조를 보이게 된다. 그때 협력들을 합치면서 두 객체를 역할로 포괄할 수 있다.

• 예상 사용자를 늘릴 경우
• 좀더 빠른 서비스 제공을 목표로 할 경우

이렇게 두 가지의 경우를 추구한다면 생각해 볼 필요가 있다.

시스템 설계도

reverse proxy

• 로드밸런싱
• ssl termination
• ip blocking
• logging

이를 위해 nginx, apache 등을 많이 사용한다. 하지만 이러한 기능들 중 로깅, ssl과 같은 부분은 톰캣에서 사용할 수 있을 것이라 결론이 나왔다.

WAS

실제 비즈니스 로직이 들어가는 부분이다. 여러 개의 WAS로 이루어질 수 있다.

Queue

비동기 방식에 주로 사용된다. 응답을 기다리지 않고 바로 리턴을 하는 방식이다. 큐 뒤에 다수의 Worker를 둬서, 대용량 처리에 유리하다. 아래와 같은 방식들로 요청이 들어오면 비동기적으로 다른 business component들(은행, 다른 서비스들 등..) 에게 알린다.

만약 payment측에서 결제 승인 웹훅을 merchant로부터 받는 방식이었다면, 웹훅이 많아질 때를 고려해 queue에 넣는 방식을 생각할 수 있다. 하지만 지금은 payment에서 웹훅을 merchant로 보내는 방식이므로, 도입한다면 merchant에 Queue를 도입하게 된다. 하지만 이 프로젝트는 payment가 메인이므로 우선순위를 낮추었다.

Data grid

session과 같은 공유 정보와 캐시 영역으로 사용된다.

DBMS

Primary Secondary 계층으로 여러 개의 db들을 둘 수 있다. CRUD는 Primary DB에서 수행하고 Primary DB의 데이타를 Staging DB로 고속 복사한후 Staging DB에서 N개의 Secondary DB로 데이타를 복사한다. Read는 Secondary DB에서 수행할 수 있다. 대부분의 서비스들은 read 요청이 많으므로 성능 향상을 낼 수 있다.

샤딩, 파티셔닝과 같은 솔루션도 고려해볼 수 있다.

Object Store

S3와 같이 이미지를 저장해 둘 때 사용하는 저장소이다.

하지만 우리 서비스와 같은 경우에는 이미지를 처리할 일이 없으므로 크게 고려하지 않았다.

CDN

자바스크립트 파일과 css, 이미지같은 잘 변화되지 않는 파일들은 불필요하게 서버에서 받을 필요가 없다. 그보다는 사용자에게 가까운 곳에 위치한 캐시 서버에서 전달을 받는 편이 빠르다.

CDN은 우리 프로젝트에서 충분히 도입할 수 있다고 생각했기에, 후에 더 알아볼 예정이다.

참고: https://bcho.tistory.com/661 https://www.slideshare.net/Byungwook/3-34910563 https://cdn.hosting.kr/cdn%EC%9D%B4%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80%EC%9A%94/

• 유연성
  • aop, di를 통해 기능을 조립하는 것이 가능하다.
  • psa
• 실용적인 javaEE 사용과 빠른 스펙의 반영
• pojo기반의 개발을 많이 하여 테스트에 용이하다.
• 어노테이션을 사용하여 편리한 개발이 가능

AOP

AOP(Aspect Oriented Programming)는 관점 지향 프로그래밍이다. 코드에서 반복되어 사용하는 부분을 부분적으로 나누어서 모듈화하는 것을 말한다. 간단히 말하면 코드에 흩어져 있는 횡단 관심사들을 aspect로 모듈화 한 것이다.

예) 로깅을 하는 aspect

package com.example.aop;

import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.stereotype.Component;

@Aspect
@Component
public class LogAspect {
    Logger logger = LoggerFactory.getLogger(LogAspect.class);

    @Around("execution(* com.example.aop.*.*(..))")
    public Object logging(ProceedingJoinPoint pjp) throws Throwable {
        logger.info("start - " + pjp.getSignature().getDeclaringTypeName() + " / " + pjp.getSignature().getName());
        Object result = pjp.proceed();
        logger.info("finished - " + pjp.getSignature().getDeclaringTypeName() + " / " + pjp.getSignature().getName());

        return result;
    }
}

실제로 실행해 보았을 때, Aspect를 적용할 컴포넌트가 존재하지 않을 경우 에러가 발생한다.

@Aspect만으로는 빈으로 등록되지 않으므로 빈으로 등록하기 위한 Component가 필요하다.

관련된 어노테이션

@EnableAspectJAutoProxy: @Aspect를 적용한 컴포넌트들을 사용할 수 있도록 설정하는 역할 @Aspect: aspect로 정의하여 AspectJAutoProxy가 사용할 수 있도록 한다. @Around: 메소드 실행 전후 공통 로직을 적용할 때 @Before: 메소드 실행 전 공통 로직을 적용할 때 @After: 메소드 실행 후 공통 로직을 적용할 때 @Component: bean을 생성하는 역할

excution

Aop가 적용될 위치를 정할 때 사용하는 pointCut의 일종이다. Advice(무엇을 할 지 정의한 부분, 여기서는 로깅)를 적용할 메서드를 등록할 때 많이 쓰인다. 표현식은 이와 같다.

execution([수식어] 리턴타입 [클래스이름].이름(파라미터)

수식어 : public, private 등 수식어를 명시합니다. (생략 가능) 리턴타입 : 리턴 타입을 명시합니다. 클래스이름 및 이름 : 클래스이름과 메서드 이름을 명시합니다. (클래스 이름은 풀 패키지명으로 명시해야합니다. 생략도 가능) 파라미터 : 메서드의 파라미터를 명시합니다. " * " : 모든 값을 표현합니다. " .. " : 0개 이상을 의미합니다.

내부 작동방식

Dynamic proxy로 동작한다. dynamic proxy가 프록시 패턴인지 데코레이터 패턴인지에 대해서는 생각해볼 가치가 있는데, 데코레이터 패턴에 가깝다고 볼 수 있다.

http://toby.epril.com/?p=841

출처: https://engkimbs.tistory.com/746 [새로비] https://jeong-pro.tistory.com/171 https://icarus8050.tistory.com/8

PSA

PSA란 환경의 변화와 관계없이 일관된 방식의 기술로의 접근 환경을 제공하려는 추상화 구조 를 뜻한다.

Java EJB가 환경에 너무 의존적이기 때문에 조금만 변화하여도 코드를 변경해야 했고, 테스트도 어려운 단점이 있었다. 따라서 이와 반대되는 POJO라는 명칭을 사용하게 되었고,

DI

함수지향

• 끝없는 복사본
• 상태 변화에 안전: 계속 복사하니 기존의 값은 안전함. 3 + 1을 한다면 새로 연산된 4는 불변성을 통해서 안전하지만, 예전의 3의 문제가 해결되는 것도 아니고 3과 1은 그대로 존재한다. 안전하게 상태를 보관했다고 보기는 어려움.
• 연산을 기반으로 로직을 전개

객체지향

• 하나의 원본: 값이 mutable함
• 상태 변화를 내부에서 책임짐: 이게 매우 어려운 점
• 메세지를 기반으로 로직을 전개

polymophism(다형성)

다형성이 갖춰지면 객체지향 언어라고 할 수 있다.

대체가능성(substitution): 확장된 객체는 원본으로 대체 가능 내적일관성(internal identy): 어때한 경우에도 태어났을 때의 원본 클래스를 유지하려고하는 속성(생성 시점의 타입이 내부에 일관성 있게 참조됨)

자바스크립트에서 내적일관성 구현방식

프로토타입 체인

worker hardworker class(function) __ proto__ --> hardworker prototype (constructor(함수의 프로토타입이므로 가지게 됨, 자기 자신을 가리키고 있음), __ proto__(객체이므로 얘도 가짐), 클래스의 메소드들)

즉,

class HardWorker extends Worker
const worker = new HardWorker();

에서 worker은 __ proto__를 가지는데, 이는 자신의 원본인 hardworker의 프로토타입을 가리킨다. hardworker의 프로토타입 또한 객체이므로 __ proto__를 가지고, 함수(function)의 프로토타입이므로 constructor을 가진다. 이는 자기 자신을 가리키고 있다. HardWorker은 Worker을 상속받았으므로, __ proto__는 Worker의 프로토타입을 가리킨다.

따라서 프로토타입 체이닝이란, 해당 객체의 __ proto__를 확인해서 원본의 프로토타입을 확인하고, 그 원본의 __ proto__를 확인하는 방식을 반복하며 진행된다. 이를 통해 constructor로 직접 원본을 확인하거나, 원본이 가진 메서드를 확인해 대체가능성과 내적일관성을 구현할 수 있다.

구현방법

먼저 그 객체의 메서드들에서 존재하는지 확인하고, 그 다음 __ proto__를 통해 부모를 확인하고 계속해서 위로 올라가며 메서드가 존재하는지 확인한다. 따라서 부모와 자식이 같은 함수를 가지고 있을 경우, 자식의 메서드가 호출되는 것이다.

자바스크립트에서 대체가능성 구현방식

A instanceof B 일 경우, 객체 A의 __ proto__를 확인하면, 원본의 constructor을 알 수 있으므로, B의 constructor와 이가 같은지 확인한다. 같지 않을 경우에는 프로토타입 체이닝을 통해 부모의 constructor을 확인한다.

객체지향에 맞는 객체

요건

• 은닉: 모든 데이터는 private이어야 한다. 상태를 외부에 보여주지 않으려면 private이 필수이다. 이렇게 되면 객체가 값으로 사용되는 일이 많아지게 되고, 객체지향이 아니게 된다.
• 캡슐화: 은닉이 변수에 대한 것이라면, 캡슐화는 메서드에 대한 것이다.(구체적인 메서드가 아니라 추상적인 메서드를 만들어야 한다.) setter와 getter로 private변수를 사용하면 제대로 된 캠슐화가 이뤄지지 않은 것이다. ex) setAge를 피하는 방법 age필드를 그대로 노출 -> setAge를 왜 하는 것인가? -> 어디에 왜 쓰는지 생각해보아야 한다. -> 나이에 따라서 컨텐츠를 구분할려고 하는 것이다 -> setAdult, setChild로 추상화해야 외부에서 내 상태를 관리하지 않고 내부에서 내 상태를 관리할 수 있다.

이유

변화에 대한 격리를 위해

SOLID원칙

• SPR: 단일 책임 원칙(이 코드를 고쳐야 하는 이유는 하나뿐인 것, 이를 지키지 못하면 shotgun surgery(산탄총 수술)이 일어난다.)
• OCP: 개방 폐쇄 원칙(extends나 implements를 하게 만들고, 기존에 있는 것들은 수정하지 않도록 만드는 것)
• 리스코프 치환 원칙: 추상층의 정의가 너무 구체적이면 구상층의 구현에서 모순이 발생함. 업캐스팅이 안전해야 하는데 추상클래스 구현이 너무 구체적이면 구현이 안되는 경우를 막아야 함
• ISP(Interface Segergation): 인터페이스 분리 (한 객체가 너무 비대해졌을 경우 소유를 사용하거나 위임을 사용하여 분리할 수 있다. 소유 방식은 사용처에 따라 객체를 하나씩 생성, 위임방식은 인터페이스를 구현한 메서드들을 오버라이드하기 때문에 인터페이스를 건드린다고 메서드에 영향이 가지 않는다.) ??????? 에바
• DIP: 의존성 역전 법칙: 다운캐스팅금지(의존성은 부모쪽으로만 흘러가야 함, 만약 instanceof C일때.. 이런 코드가 들어가있으면 다운캐스팅을 하고 있는 것, 즉 자식쪽에 의존하고 있는 것이므로 코드를 잘못 짜고 있는 것이다.)

고차원의 모듈은 저차원의 모듈에 의존하면 안된다. 이 두 모듈 모두 추상화된 것에 의존해야 한다.???? DI: 의존성 주입 IOC: 제어 역전 DRY(Don't Repeat Yourself): 중복 방지 Hollywood Principle: 의존성 부패방지(부모클래스는 서브클래스에 정의된 연산에 대한 호출을 할 수 있지만 그 반대방향은 일어나면 안 된다. 이렇게 어떤 대상에게 질의를 하게 되면 은닉, 캡슐화를 잊게 된다) Law of demeter: 어떠한 객체에 대해 최소한의 지식만 알아야 함, 의존성의 부패를 막기 위해

• 최소한의 지식 classA.methodA의 경우
  • classA의 필드 객체
  • methodA가 생성한 객체
  • methodA의 인자로 넘어온 객체

메세지

SRP

단일 책임 원칙을 준수하는 객체에게 그 이상의 업무를 부여하면

• 만능 객체가 되려 한다
• 다른 객체한테 의뢰한다.

다른 객체에게 의뢰하는 것 = 다른 객체에게 메세지를 보내는 것

• 메세지: 의뢰할 내용
• 오퍼레이션: 메세지를 수신할 객체가 제공하는 서비스
• 메소드: 오퍼레이션이 연결될 실제 처리기 오퍼레이션이 호출되면 그때에 따라 다른 메소드가 호출되는 것을 동적 바인딩이라고 한다.

오퍼레이션과 메소드를 분리해서 상황에 따라 원하는 메소드를 호출하기 위해 추상클래스나 인터페이스를 상속시킨다.(OCP)

의존성

의존성이 있으면 의존되는 관계에 있는 객체들의 영향을 그대로 받는다. => 격리성을 높여야 너무 의존성이 없으면 만능 객체가 태어나게 됨. 너무 의존성이 크면 한 객체가 수정되거나 추가되면 다른 객체들이 전부 영향을 가지게 된다. 따라서 적당한 의존성을 가져야 한다.

의존성 만드는 방법

객체의 생명 주기 전체에 걸친 의존성

• 상속: 매우 강력해서 부모 객체가 바뀌면 수정될 것을 각오해야 한다.

• 연관: 필드에 객체를 저장해놓는 것.(소유)

각 오퍼레이션 실행 시 임시적인 의존성 -> 의존: 오퍼레이션 실행 시에만 연결이 되고, 메서드 호출이 되면 의존성이 생기고 호출이 끝나면 의존성이 사라지는 약한 의존성을 가진다.

연관에서 의존으로 바꾸기 위해서는 상태를 저장해놓는 방식을 포기해야 한다. 그러면 함수형 아니냐, 따라서 쉽게 바꾸지 못함

높은 의존성 단점

• 수정 여파 규모증가
• 수정하기 어려운 구조 생성
• 순환 의존성

의존성 역전

어떠한 경우에도 다운캐스팅은 금지하고 다형성 사용하는 것. DIP와 OCP는 깊은 연관을 가지고 있다. 부모쪽에 의존성을 가지면, 새로운 자식이 추가되어도 기존의 코드는 수정되지 않아 OCP가 이뤄진다고 볼 수 있기 때문이다.

자신있는 분야가 뭐에요?

지원동기가 뭐에요?

가장 도전적이었던 프로젝트 설명해주세요

어떤 부분이 제일 힘들었어요?

webflux가 뭐에요?

webflux왜 사용했어요?

mysql왜 사용했어요?

기본적인 내용은 아래의 블로그를 따라가면 된다. 하지만 내가 고생했던 부분과 팁을 첨부해 글을 적어 놓으려고 한다. 참고로 mysql 5.6이상만 utf8mb4를 지원한다. 우리는 다행히 5.6.6을 사용하고 있었다.

How to support full Unicode in MySQL databases

1. amazon rds 파라미터 설정

기존에 디폴트 파라미터 그룹을 사용했다면, 새로운 amazon rds 파라미터 그룹을 생성하여 거기에 설정해 준다.

설정은 각 블로그마다 달랐지만, 기본적으로는 character_set과 collation과 관련 파라미터를 모두 utf8mb4, utf8mb4_unicode_ci로 설정하면 된다.

블로그에 있는 글을 참고하면

http://jinolog.com/programming/mysql/2011/03/21/character-set-and-collation.html

문자셋(Character set)은 각 문자가 컴퓨터에 저장될 때 어떠한 '코드'로 저장될지에 대한 규칙의 집합을 의미하며 콜레이션(Collation)은 특정 문자 셋에 의해 데이터베이스에 저장된 값들을 비교 검색하거나 정렬 등의 작업을 위해 문자들을 서로 '비교' 할때 사용하는 규칙들의 집합을 의미한다.

이라고 한다.

만든 파라미터 그룹을 해당 디비에 적용한 다음 재부팅 반드시 잊지말자! 재부팅을 안할 시 해당 설정이 제대로 안먹는 경우도 발생한다.

(2. 로컬에서 설정)

먼저 아마존의 파라미터 그룹 설정이 잘 적용되었는지 확인한다.

show variables like'char%'

잘 적용되지 않았을 경우에는 해당 파라미터에 대해 set 'Variable_name'=utf8mb4를 이용해 적용한다.

3. 기존 DB 설정

만약 디비를 새로 생성하는 것이라면 괜찮지만, 기존 디비에서 설정을 바꿔야 할 경우에는 추가적인 작업이 필요하다. 맨 처음 블로그를 보면 일일히 모든 디비, 칼럼, 테이블을 이렇게 설정하라고 나와 있다. 디비정도는 괜찮지만, 테이블, 칼럼에 대해서는 너무 노가다인게 사실이다.

For each database:

ALTER DATABASE database_name CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci;

For each table:

ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

For each column:

ALTER TABLE table_name CHANGE column_name column_name VARCHAR(191) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; (Don’t blindly copy-paste this! The exact statement depends on the column type, maximum length, and other properties. The above line is just an example for a VARCHAR column.)

따라서 아래의 쿼리문을 이용하면 테이블의 설정을 간편하게 바꿀 수 있다.

SELECT CONCAT('ALTER TABLE ', TABLE_NAME, ' CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8_unicode_ci;')
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'my_database_name' AND TABLE_TYPE != 'VIEW';

하지만 칼럼에 대해서는 답이 없다. 해당 칼럼마다 특성이 다르기 때문에 일반적인 쿼리문을 작성하기 어렵기 때문이다. 따라서 일일히 위처럼 해준다...

지금까지 적용한 속성들을 다 확인하기 위한 쿼리문이다.

##디비 설정 확인
select * from information_schema.SCHEMATA S;
## 해당 테이블에 대한 칼럼 설정 확인
SELECT character_set_name FROM information_schema.`COLUMNS` WHERE table_name = 'posts';
## 모든 테이블에 대한 칼럼 설정 확인
    SHOW VARIABLES WHERE Variable_name LIKE 'character\_set\_%' OR Variable_name LIKE 'collation%';

참고

하지만 datagrip에서 이모지가 들어간 row를 넣으려고 하면 ?로 변환된다.. mysql의 설정이 안먹어서 그런 줄 알았는데 그냥 datagrip이 utf8mb4를 지원하지 않는 것 같아 별도의 datagrip gui설정이 필요한 것 같다.

식은 하나의 값으로, 일반 문은 실행 단위(레코드)로 등록되고 flow를 따른다.

flow control를 할 수 있는 문들을 이용하면, 레코드를 선택하거나 레코드를 순환할 수 있게 된다. 이런 문들을 completion record로 바뀐다.

직접 flow control

label

문이 아니라 record에 달아주는 태그같은 것이므로 자체로는 문, 레코드가 될 수 없고 별다른 문이 없으면 에러가 난다. 레이블의 이름은 같은 스코프에 두개 등장할 수 없고 이는 컴파일 타임에 에러가 잡힌다.

스코프

스코프의 종류: 블록 스코프, 함수 스코프

label 스코프를 만들 수 있다. a:{}는 중문과는 또 다르다. 같은 함수 스코프 내에는 똑같은 이름의 레이블을 선언할 수 없다. 하지만 레이블 스코프 내에는 같은 이름의 레이블을 또 만들 수 있다.

스코프 범위

일반적으로 레이블 스코프가 지정되지 않을 경우 다른 lablel이 등장하기 전 까지 auto label일 경우 레이블 스코프가 자동적으로 지정된다. iteration, switch위에 label을 작성하게 되면 그 문이 끝날 때까지로 레이블이 자동적으로 한정된다.

특정한 경우, label안에서는 그걸 빠져나오기 위한 flow control이 가능해지고(위로 이동하는 것은 불가능), break, 루프의 경우 switch도 가능해진다.

• label 스코프를 선언한다.
• iteration label이 된다.
• switch label이 된다.

for문에서 어떻게 break를 사용할 수 있는가?

보통 label문에서는 break 뒤에 label이름을 적는데, for문 위에 auto label이 생성되고, break를 쓰면 뒤에 자동으로 break "auto label name"이 되어 작동한다.

switch

구성요소

switch + (식) + {} 하지만 if문이나 for문 뒤의 중괄호는 단문이 나와도 되어서 생략될 수 있었던 반면, switch문의 중괄호는 생략되면 안된다. 이유: switch문 중괄호는 special label block을 만들어주는 역할을 하기 때문이다. 이를 통해 컴파일 타임에 해석되는 정적인 레이블을 만드는 것이 아니라, 동적으로 해석할 수 있는 케이스 레이블을 사용할 수 있다.

case label 평가방식

자바에서는 switch문이 나오면 케이스와 문에 대한 맵을 생성하여서 default문을 앞에 두어도 해당되는 케이스만 수행된다. -> case label에 식이 들어가면 안 된다. 반면 자바스크립트는 case label에 식이 들어가도 런타임으로 평가가 가능하다.

평가방식

값에 대한 평가, 값을 true를 통해 무력화시키고 case를 통해 평가(책임 연쇄 패턴)

컴파일 프로그램

컴파일 언어 프로그램의 생명주기는 Language Code(Lint Time) -> Machine Language(Compile Time) -> File -> Load -> Run(Run time) -> Terminate 이다. Load되어 컴퓨터에 올라간 것을 프로그램이라고 한다.

스크립트 프로그램

스크립트 언어 프로그램의 생명주기는 Language Code -> File -> Load -> Machine Language -> Run -> Terminate 이다. 일반 프로그램과는 달리 컴파일이 되지 않고 로드된 후에 컴파일을 하고 실행된다. 자바스크립트도 스크립트 언어이기 때문에 코드를 브라우저에 로딩하고 로드가 끝난 다음에 컴파일을 하고 실행한다.

런타임?

메모리

코드는 명령부분과 데이터부분으로 나눠져서 메모리에 적재된다.

CPU

CPU는 4가지로 구성된다.

• 외부 입출력 인터페이스(캐시 레이어, 외부 버스): 메모리로부터 명령을 전달받고, 캐싱하거나 자신의 CPU에 맞는 명령으로 해석한다.
• 제어유닛: 디코딩을 한다. 추상적인 명령을 CPU가 알 수 있는 명령으로 디코딩한다.
• 연산유닛: 제어유닛과 데이터유닛에서 명령과 값을 받아와 연산한다.
• 데이터유닛: 메모리의 데이터부분을 받아와서 연산유닛에 넘긴다.

그래서 런타임이란? Load (메모리에 적재) -> Run

• instruction fetch(외부 버스에서 자신의 CPU가 이해할 수 있도록 명령을 바꿔준다.) & decoding (제어유닛에서 연산유닛이 알 수 있도록 디코딩)
• Execution: 연산 유닛의 결과를 데이터유닛에 전달하고, 이것은 메모리에 전달된다.

Load->Run은 어떻게 진행?

컴파일 프로그램

컴파일러는 어떻게 메모리에 적재되지 않아서(로드가 되지 않음) 물리적인 메모리를 갖고있지도 않은 상태에서 코드를 검증하지?

• 컴파일러가 language code를 해석할 때 가상 메모리 상에서 테스트를 해본 것이다. 코드가 검증되면 V테이블을 이용해 가상 메모리를 진짜 메모리와 매핑한다.

essential definition loading (프로그램 실행에 반드시 필요한 것들을 컴파일할 때 메모리에 적재) -> v table mapping (로딩하고 실행하기 전에 가상 메모리와 진짜 메모리를 매핑) -> run -> runtime definition loading -> run

이처럼 컴파일 시점에서 확정되는게 아니라 런타임에서 정의되기도 한다.

스크립트 프로그램

1. 기본이 되는 함수들이나 클래스가 정의된다.
2. 런타임에서도 위를 이용해 커스텀 함수들이나 클래스가 정의된다.

따라서 스태틱과 런타임이란 상대적인 것이다. 1번이 정의되어야만 2번이 정의될 수 있으므로 2번에게 1번은 static이 된다.

프로그램이 작동하는 방식

참조의 참조를 왜 쓰는가?

메모리, 주소, 포인터, 변수, 디스패치(주소로부터 값을 얻는 행위)가 존재한다.

A의 메모리 참조를 가지고 있는 B를 직접참조한 C가 있다. 여기서 B가 다른 메모리를 참조하더라도, C는 계속해서 자신은 B를 가지고 있다고 생각하고, 여기서 에러가 발생한다. 이처럼 참조를 복사하면 큰 문제가 일어난다.

함수형 프로그래밍에서는 참조를 사용하지 말도록 한다. 객체지향 프로그래밍에서는 직접참조하지 않도록 더블 디스패치로 해결한다.

자바스크립트의 특성

자바스크립트를 구성하는 텍스트 요소

• control character: 제어문자
• white space: 공백문자
• line terminators: 개행문자
• comments: 주석
• keyword: 예약어(변수나 식별자로 사용할 수 없음)
• literal: 더 이상 나눌 수 없는 객체나 값의 표현

자바스크립트 언어를 구성하는 요소

• statememt: 문
  • 처리될때 처리를 위한 힌트로 사용하고 결과는 메모리에 남지 않는 것
  • 종류: 공문(" ;"), 식문, 제어문, 선언문(메모리 상에 변수를 할당하는 일. 주소, 타입, 크기를 v테이블에 기록해놓는다.)
  • 종류: 단문, 중문({}) ex) if의 구성요소는 if+(식)+문이어서 단문일 경우도 중문으로 묶지 않아도 실행된다.
• expression: 식
  • 값식, 연산식, 호출식(함수 호출을 하면 값이 나옴)
  • 결과로 값이 나온다.
  • 식을 문으로 인정한다.
• identifier: 식별자
  • 기본형, 참조형

흐름이란?

명령이 순서대로 실행되는 과정을 흐름이라고 한다. 원래 메모리에 적재되는 명령어를 수행하는 동안 간섭하지 못한다. 하지만 제어문을 이용해 flow control을 할 수 있다. 함수나 클래스를 이용해 sub flow도 만들 수 있다.

#include <map>

유용한 방식

넣고 빼기

map<int, int> m;
m[4] = 4;
m.insert({4,4});
cout << m[4] << endl;

하지만 m[4]와 같은 식으로 접근할 경우 원소가 없으면 0을 리턴에 원소가 실제로 존재하지 않는지 확실히 알 수 없다. 따라서 m.find(4)와 같이 접근해야 원소가 있는지 없는지 확실히 알 수 있다.

if (m.find(5) == m.end())

find는 원소가 없을 시 마지막 원소를 리턴한다.

삭제

//m : [{4,4}]
m.erase(4);
//m : []

순회

map에는 pair을 넣기에 pair와 똑같은 방식으로 값에 접근한다.

for (map<int, int>::iterator i = m.begin(); i != m.end(); i++)
    {
        cout << i->first << i->second;
    }

auto를 사용하면 포인터 참조를 하지 않아도 된다.

for (auto i = m.begin(); i != m.end(); i++)
    {
        cout << i.first << i.second;
    }