1. setter 지양

setter통한 로직이 많아지면 객체의 일관성, 안정성이 불안하다
변경 포인트가 너무 많아져서 유지 보수가 어렵다

1-1 생성자 통해서

  public User(String team, String username, int password){
      this.team = team;
      this.username = username;
      this.password = password;
  }

1-2 builder 패턴

User newUser = User.builder()
                        .username(user.getUsername)
                        .password(passwordEncoder.encode(user.getPassword)
                        .name(user.getName).build();

builder 패턴 장점

- 인자명을 확인할 수 있음으로 의미를 알기 쉬움
- 인자 추가 혹은 제거 시 코드 수정하기 간펺 = 오버라이딩 불필요

2. 관심사 분리

• 클래스의 책임과 역할이 명확

• Class에 있어서 최소한의 기능을 갖도록 구성해야 추후 변경사항에 유연하고 확장성있음.

• 유지보수 시 복잡성 줄이고 및 재사용성 높임. 개별 부문 이해하기 쉬움

• Test 할 때, 격리된 독립 모듈 테스트 하는 것이 용이
  ex. Layer간,

  2-1. SRP: 한 객체의 하나의 책임만 갖도록 설계

  				= 객체를 변경시키는 이유는 한 가지
                 

• 클래스 내부 코드들간 결합성 높아진다

• 클래스 간 결합성이 높아진다 = 유연성, 확장성 떨어짐

• 코드는 결합성이 낮고, 결합성이 높아야 한다.

예제
https://velog.io/@damiano1027/Java-%EA%B0%95%ED%95%9C-%EA%B2%B0%ED%95%A9%EA%B3%BC-%EC%95%BD%ED%95%9C-%EA%B2%B0%ED%95%A9

3. JPQL, QueryDSL

ORM: 객체와 관계형 데이터베이스의 데이터를 자동으로 매핑

JPA : 엔티티 객체를 중심으로 개발을 하므로 SQL을 사용하지 않는다.
모든 테이블을 메모리에 올려서 필터링하는 것은 말이 안된다. a.getB().getC()
하지만 검색쿼리를 사용 시 SQL을 사용해야할 때가 필요.

[객체지향 쿼리: 테이블이 아닌 entity 객체를 대상으로 검색]

• SQL을 추상화한거라 db에 의존 X, JPA가 이거를 SQL로 바꿔줌

JPQL : SQL 테이블 대상, JPQL 엔터테 객체 대상으로 쿼리.

QueryDsl: 자바코드로 JPQL 작성하게 해주는 JPQL 빌더 역할, 컴파일 시점 오류 잡음, 동적 쿼리

JPA는 엔티티 객체를 중심으로 개발하므로 검색을 할 때도 테이블이 아닌 엔티티 객체를 대상으로 검색해야 한다.

4. DTO

4-1 DTO, VO 차이

VO는 read-only속성을 가진 객체로 데이터 그 자체에 의미가 있다
Request올 때 정도로만 사용된다

4-2 DTO 필요성

- API 스펙과 Entity 간 의존성이 생긴다. 
  Response 스펙에 맞추기 위해 Entity에 프레젠테이션 계층을 위한 로직을 추가해야한다. ex. @JsonIgnore 등
- 여러 서비스, 비즈니스 로직이 Entity기준으로 동작함. 
  변경요소가 많은 DTO와 분리되야 한다. 데이터 모델링 유지
- Entity의 외부 노출 방지

5. IOC,DI,DIP

6. 커넥션풀(DBCP)

WAS가 실행되면서 DB와 미리 connection(연결)을 해놓은 객체들을 pool에 저장해두었다가.
클라이언트 요청이 오면 connection을 빌려주고, 처리가 끝나면 다시 connection을 반납받아 pool에 저장하는 방식

여기서 WAS에서 커넥션 풀을 크게 설정하면 메모리 소모가 큰 대신 많은 사용자가 대기시간이 줄어들고, 반대로 커넥션 풀을 적게 설정하면 그 만큼 대기시간이 길어진다.