• 클래스는 객체를 만들기 위한 일종의 설계 도면이며, 객체의 특성과 동작을 정의한다.

• 클래스는 데이터와 함수를 묶어 놓은 구조로, 객체를 생성하기 위한 틀이라고 할 수 있습니다.

객체란?

• 프로그래밍에서 데이터와 해당 데이터를 조작하기 위한 동작(메서드 또는 함수)을 하나로 묶은 개념이다.
• 객체는 속성과 기능, 두 종류의 구성요소로 이루어져 있으며, 일반적으로 객체는 다수의 속성과 다수의 기능을 갖는다.
• 즉, 객체는 속성과 기능의 집합이라고 할 수 있다.

인스턴스란?

• 인스턴스는 클래스를 기반으로 실제로 메모리에 생성된 객체를 나타낸다.
• 클래스의 설계에 따라 여러 개의 인스턴스를 생성할 수 있으며, 각각의 인스턴스는 독립적인 데이터와 동작을 가진다.
• 클래스로부터 객체를 만드는 과정을 클래스의 인스턴스화라고 하며, 어떤 클래스로부터 만들어진 객체를 그 클래스의 인스턴스라고 한다.

인스턴스와 객체

• tv클래스로부터 만들어진 객체를 tv 클래스의 인스턴스라고 한다. 결국 인스턴스는 객체와 같은 의미이지만, 객체는 모든 인스턴스를 대표하는 포관적인 의미를 갖고 있으며, 인스턴스는 어떤 클래스로부터 만들어진 것인지를 보다 강조하는 의미를 갖고있다.
• 예를 들면, '책상은 인스턴스다.'라고 하기 보다는 '책상은 객체다'라는 쪽이, '책상은 책상 클래스의 객체이다' 라고 하기 보다는 '책상은 책상 클래스의 인스턴스다'라고 하는 것이 더 자연스럽다

• 유저 초대, 권한 부여 기능구현
• AOP, Exction 구현
• postman으로 테스트

[프로젝트] Trello

🙃 커스텀 어노테이션

• AOP에서 메서드들을 상황별로 묶어 좀더 효율적으로 할 수 있는 방법을 찾았고 적용해서 AOP 구현 했다.

[Spring] 커스텀 어노테이션

🙃 N+1

• UserBoard 엔티티에서 ManyToOne 관계로 User 엔티티를 참조하고 있다. UserBoard 엔티티에서 userId를 사용해 사용자 ID에 해당하는 보드를 조회하려고 했다. 이럴 경우, 각각의 보드마다 해당 보드의 작성자인 사용자 정보를 가져오기 위해 추가 쿼리를 실행하게 된다. 이로 인해 사용자마다 보드 개수만큼 추가적인 쿼리가 실행되어 N+1 문제가 발생한다.

public interface UserBoardRepository extends JpaRepository<UserBoard, Long> {
    List<UserBoard> findAllByUserId(Long userId);
}

• 해결 : Fetch join 주어진 사용자 ID에 해당하는 모든 유저보드 엔티티를 가져오면서 작성자 정보를 함께 가져와서 추가적인 쿼리 없이 N+1 문제를 해결할 수 있었다.

public interface UserBoardRepository extends JpaRepository<UserBoard, Long> {
    @Query("SELECT ub FROM UserBoard ub JOIN FETCH ub.board WHERE ub.user.id = :userId")
    List<UserBoard> findAllByUserIdWithUserFetch(Long userId);
}

보드 관리 기능

• 보드 초대

    - 특정 사용자들을 해당 보드에 초대시켜 협업을 할 수 있어야 합니다.
    - 보드 생성자만 초대 가능
    - 초대된 유저는 member 적용
    - 초대된 유저는 다시 초대 불가능

🐾 이메일 인증을 통한 초대를 구현하고 싶었는데 팀 프로젝트이고 일정이 일주일 밖에 되지 않아 아쉽지만 간단하게 구현하기로 했다. 보드 생성자만이 초대를 할 수 있고 초대된 유저는 member로 userBoardRepository에 저장된다.

추가 기능

• 회원 권한 부여
  • MEMBER → ADMIN, ADMIN → MEMBER
  • 보드 생성자만 회원 권한 부여 가능

이슈

🔥 N+1

• UserBoard 엔티티에서 ManyToOne 관계로 User 엔티티를 참조하고 있다. UserBoard 엔티티에서 userId를 사용해 사용자 ID에 해당하는 보드를 조회하려고 했다. 이럴 경우, 각각의 보드마다 해당 보드의 작성자인 사용자 정보를 가져오기 위해 추가 쿼리를 실행하게 된다. 이로 인해 사용자마다 보드 개수만큼 추가적인 쿼리가 실행되어 N+1 문제가 발생한다.

public interface UserBoardRepository extends JpaRepository<UserBoard, Long> {
    List<UserBoard> findAllByUserId(Long userId);
}

👏🏻 해결

• Fetch join
  • 주어진 사용자 ID에 해당하는 모든 유저보드 엔티티를 가져오면서 작성자 정보를 함께 가져와서 추가적인 쿼리 없이 N+1 문제를 해결할 수 있다.

public interface UserBoardRepository extends JpaRepository<UserBoard, Long> {
    @Query("SELECT ub FROM UserBoard ub JOIN FETCH ub.board WHERE ub.user.id = :userId")
    List<UserBoard> findAllByUserIdWithUserFetch(Long userId);
}

🔥 AOP & 커스텀 어노테이션

• [Spring] 커스텀 어노테이션

• 처음에는 pointcut을 메서드 별로 사용했는데 너무 비효율적이라는 생각이 들었다. 그리고 상황별로 나눠서 메서드를 묶어 처리하고 싶었다.

• 찾아보니 커스텀 어노테이션을 통해서 메서드에 어노테이션을 추가해 일괄 처리할 수 있었다.

👏🏻 해결

• AccessCheck 커스텀 어노테이션을 만들어 일괄 처리 하였다.

/*ExcludeLogging 어노테이션을 메서드에만 적용할 수 있도록 지정*/
@Target(ElementType.METHOD) 
/*ExcludeLogging 어노테이션이 런타임까지 유지되도록 지정*/
@Retention(RetentionPolicy.RUNTIME) 
public @interface AccessCheck {
}

@Pointcut("@annotation(com.example.tenrello.board.aop.AccessCheck)")
    private void accessCheckMethods() {
    }

    @Around("accessCheckMethods()")
    public Object boardAccessCheck(ProceedingJoinPoint joinPoint) throws Throwable {
        Object[] args = joinPoint.getArgs();

            User user = (User) joinPoint.getArgs()[0];
            Long boardId = (Long) joinPoint.getArgs()[1];

            Board board = boardService.findByBoard(boardId);

            if (userBoardRepository.findByBoardIdAndUserId(boardId, user.getId()).isEmpty()) {
                log.warn("초대 받지 못한 유저입니다.");
                throw new BoardAccessException("초대 받지 못한 유저입니다.");
            }

        return joinPoint.proceed();
    }

메타 어노테이션

• @Retention : 컴파일러가 어노테이션을 다루는 방법을 기술, 어느 시점까지 영향을 미치는지를 결정

  • RetentionPolicy.SOURCE : 컴파일 전까지만 유효 RetentionPolicy.CLASS : 컴파일러가 클래스를 참조할 때까지 유효 RetentionPolicy.RUNTIME : 컴파일 이후 런타임 시기에도 JVM에 의해 참조가 가능(리플렉션)

• @Target : 어노테이션 적용할 위치 선택

  • ElementType.PACKAGE : 패키지 선언 ElementType.TYPE : 타입 선언 ElementType.ANNOTATION_TYPE : 어노테이션 타입 선언 ElementType.CONSTRUCTOR : 생성자 선언 ElementType.FIELD : 멤버 변수 선언 ElementType.LOCAL_VARIABLE : 지역 변수 선언 ElementType.METHOD : 메서드 선언 ElementType.PARAMETER : 전달인자 선언 ElementType.TYPE_PARAMETER : 전달인자 타입 선언 ElementType.TYPE_USE : 타입 선언

• @Documented : 해당 어노테이션을 Javadoc에 포함시킴

• @Inherited : 어노테이션의 상속을 가능하게 함

• @Repeatable : Java8 부터 지원하며, 연속적으로 어노테이션을 선언할 수 있게 함

커스텀 어노테이션 만들기

1. 인터페이스 앞에 @를 붙여서 생성할 수 있다.

2. 메타 어노테이션 추가

3. 적용할 어노테이션 추가

4. 변수 추가

5. 적용 하기

@RestControllerWithSwagger(value = "RestMemberController", name = "RestMemberController")
@RequiredArgsConstructor
@Test1
@RequestMapping("/member")
public class RestMemberController {

    private final MemberService memberService;

    @ApiOperation("멤버 목록 반환")
    @GetMapping("/list")
    public ResponseEntity<String> upload() {
        return ResponseEntity.ok(memberService.getList());
    }

}

참고

[Java] Custom Annotation(커스텀 어노테이션) 만들기 [Java] 어노테이션 (+커스텀 어노테이션 만들기)

       [프로젝트] Trello

📋 CS

       MVC 패턴

✏️ 알고리즘

       Algorithm

• Create

• Read (사용자가 속한 보드 리스트)

• Update

• Delete

API 수정

• 보드 관리 기능
  • 보드 생성
  • 보드 수정
    • 보드 이름
    • 배경 색상
    • 설명
  • 보드 삭제
    • 생성한 사용자만 삭제를 할 수 있습니다.

Model-View-Controller 의 약어로 애플리케이션을 세 가지 역할로 구분한 개발 방법론

Model

데이터와 비즈니스 로직을 관리한다.

• 데이터는 내부의 상태에 대한 정보를 가질 수도 있고, 모델을 표현하는 이름 속성으로 가질 수 있다.

• 모델의 상태에 변화가 있을 때 컨트롤러와 뷰에 이를 통보한다.

• 이와 같은 통보를 통해 뷰는 최신의 결과를 보여줄 수 있고, 컨트롤러는 모델의 변화에 따른 적용 가능한 명령을 추가, 제거, 수정할 수 있다.

규칙

1. 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야만 한다.
2. 뷰나 컨트롤러에 대해서 어떠한 정보도 알지 말아야 한다.
3. 변경이 일어나면, 변경 통지에 대한 처리 방법을 구현해야 한다.

View

레이아웃과 화면을 처리한다.

• 항목이 사용자에게 보여지는 방식을 정의하며, 표시할 데이터를 모델로부터 받는다.

규칙

1. 모델이 가지고 있는 정보를 따로 저장해서는 안된다.
2. 모델이나 컨트롤러와 같이 다른 구성 요소를 몰라야 함
3. 변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야 함

Controller

앱의 사용자로부터의 입력에 대한 응답으로 모델 및/또는 뷰를 업데이트하는 로직을 포함

• 입력이 컨트롤러에게 전송되고, 모델을 적당하게 처리한다음, 업데이트된 데이터를 뷰로 전송해서 사용자에게 알려준다.

규칙

1. 모델이냐 뷰에 대해서 알고 있어야 함
2. 모델이나 뷰의 변경을 모니터링해야 함

• 사용자가 Controller를 조작하면 Controller는 Model을 통해 데이터를 가져오고 그 데이터를 바탕으로 View를 통해 시각적 표현을 제어하여 사용자에게 전달하게 된다.

1. 사용자가 웹사이트에 접속 (Users)
2. Controller는 사용자가 요청한 웹페이지를 서비스하기 위해서 모델을 후출 (Manipulates)
3. Model은 데이터베이스나 파일과 같은 데이터 소스를 제어한 후 그 결과를 Return
4. Controller는 Model이 리턴한 결과를 View에 반영 (Updates)
5. 데이터가 반영된 View는 사용자에게 보여진다. (Sees)

MVC 패턴 방식

• 웹브라우저 사용자의 요청을 서블릿이 받고 서블릿은 해당 요청으로 View로 보여줄 것인지 Model로 보낼 것인지를 판단하여 전송한다. HTML 소스와 JAVA소스를 분리해놓았기 때문에 확장시키기도 쉽고 유지보수 또한 쉽다.

장점

• 디자이너와 개발자의 분업이 가능하며 유지보수 및 확장이 쉬움

단점

• 설계가 어려우며 개발 난이도가 높음

MVC 패턴을 사용해야 하는 이유

• 비즈니스 로직과 UI로직을 분리하여 유지보수를 독립적으로 수행가능
• Model과 View가 다른 컴포넌트들에 종속되지 않아 애플리케이션의 확장성, 유연성에 유리함
• 중복 코딩의 문제점 제거

MVC 패턴의 한계

• MVC패턴에서 View는 Controller에 연결되어 화면을 구성하는 단위 요소이므로 다수의 View를 가질 수 있습니다. 그리고 Model은 Controller를 통해서 View와 연결되지만, Controller에 의해서 하나의 View에 연결될 수 있는 Model도 여러 개가 될 수 있어 View와 Model이 서로 의존성을 띄게 됩니다. 즉, Controller에 다수의 Model과 View가 복잡하게 연결되어 있는 상황이 발생할 수 도 있습니다.

참고

MVC [개발상식] MVC 패턴이란? (Model-View-Controller)

• 역할 : 보드 생성, 수정, 삭제 및 초대 구현 추가 : ADMIN, MEMBER 역할 부여, 보드 조회

• 고민해 봐야할 문제 : UserBoard entity에 저장할 권한을 어디서 받아올 것인지, 초대는 어떤 방식을 사용할 것인지?

       [1차설계] Trello S.A

🙃 프로젝트 진행하면서 당연한 이야기지만 테스트를 위해 포스트맨을 처음 사용할 때 mySql 연결 후 사용한다. 평소와 다르지 않은 날이였는데... 분명 그랬는데 처음 보는 에러를 만났다. db도 drop해보고, 삭제하고 다시 생성도 해보고, MYSQL에서 select database(); 로 계속 확인도 해봤지만 테이블이 생성되지 않으면서 저 에러가 자꾸 생겼다. 그러던 중 ddl-auto를 update가 아닌 none으로 설정한게 생각이 나서 바꿔줬더니 됐었다! 별거 아닌거에 시간을 너무 잡아먹었지만 이렇게 된거 제대로 알고가자는 마음에 정리해봤다. 정리하면서 느낀점은 이거!!! 지금 이라도 알아서 참 다행이다!

SQL Error: 1146, SQLState: 42S02

       [Spring] ddl-auto 옵션

✏️ 알고리즘

       Algorithm

📋 CS

       DI와 IoC

팀명

• Tenrello

API

ERD

와이어 프레임

• 메인 페이지

• 로그인

• 마이 페이지

• 카드 페이지

🐣 역할

• 보드 관리 기능
  • 보드 생성
  • 보드 수정
    • 보드 이름
    • 배경 색상
    • 설명
  • 보드 삭제
    • 생성한 사용자만 삭제를 할 수 있습니다.
  • 보드 초대
    • 특정 사용자들을 해당 보드에 초대시켜 협업을 할 수 있어야 합니다.

• 알고리즘 및 CS 스터디를 주 5일 하는중이다. 알고리즘은 하루에 0Lv을 3-4문제씩 풀고, CS는 목터뷰 면접 질문에서 한문제씩 맡아서 설명해주는 방식으로 진행중이다. 그리고 알고리즘을 벨로그에 하나 하나 정리했는데 백준 허브 확장 프로그램을 이용해서 이제는 깃허브에 자동 커밋된다!!! 백준 허브 최고!!

       Algorithm

📋 CS

• 스터디에서 면접 질문 답을 위해 정리하는 과정에서 헷갈리거나 모르는 내용을 알아가는 과정이 굉장히 흥미롭다!

       배열과 연결 리스트 비교        CORS        시간복잡도 및 공간복잡도        DI와 IoC

🔥 그 외 AOP, JPA 심화 AWS 등을 들었는데 이것들은 정리가 좀 더 하고 깃허브에 push할 예정이다.

       [Spring] AOP        [JPA] ORM 의 탄생 배경 (JDBC, Query Mapper)

데이터베이스 스키마를 자동으로 생성, 수정 또는 삭제하는 기능

ddl-auto 옵션 종류

• create : 기존테이블 삭제 후 다시 생성 (DROP + CREATE)

• create-drop: create : create와 같으나 종료 시점에 테이블 DROP

• update : 변경분만 반영 (운영DB 에서는 사용하면 안됨)

• validate : 엔티티와 테이블이 정상 매핑되었는지만 확인

• none : 사용하지 않음 (사실상 없는 값이지만 관례상 none이라고 한다.)

⭐ 주의할 점

• 운영 장비에서는 절대 create, create-drop, update 사용하면 안된다.

• 개발 초기 단계는 create 또는 update

• 테스트 서버는 update 또는 validate

• 스테이징과 운영 서버는 validate 또는 none

평소 update를 사용한다. 엔티티의 필드를 삭제한후 실제 테이블을 확인하면 반영되지 않는다. 이유를 알아보자!!

문제 원인

update의 특성

• update 옵션이 엔티티 상태에 따라 테이블을 수정하는 옵션이기 하지만, 칼럼 삭제의 경우에는 해당되지 않는다.

• 즉 ddl-auth=update 를 통해 칼럼을 삭제할 수 없다.

왜?

• 이러한 동작은 의도된 설계이다.

• 왜냐하면, 레거시 DB를 사용할 수 있도록 허용한 것이기 때문이다.

• 즉 과거에 사용하던 DB를 사용할 수 있도록 설계된 사항이다.

해결 방안

1. ddl-auto=create-drop 을 사용한다.

2. 직접 SQL을 작성하여 칼럼 삭제한다.

3. 파일을 DROP 시키고 다시 빌드한다.

• 제어의 역전 이라는 의미로, 말 그대로 메서드나 객체의 호출작업을 개발자가 결정하는 것이 아니라, 외부(프레임워크나 컨테이너)에서 결정되는 것을 의미한다.

• 간단히 말해 제어의 흐름을 바꾼다 라고 한다.

제어가 역전된 경우

• 아래 코드는, A 객체는 B 객체에 의존하고 있다를 보여준다. 제어를 개발자가 관리하고 있다.

public class A {

    private B b;

    public A() {
        b = new B();
    }
}

• 하지만 Spring에서는 @Autowired를 통해 객체를 주입받는다.

  public class A {
    @Autowired
    private B b;
  }

  • B라는 객체가 스프링 컨테이너에게 관리되고 있는 Bean 이라면 @Autowired를 통해 객체를 주입받을 수 있게 된다. 이것은 스프링 컨테이너에서 직접(제어) 객체를 생성하여 해당 객체에 주입 시켜준 것이다.

• 이것이 바로 제어가 역전된 경우다 개발자가 해야 할 제어를 스프링 컨테이너에서 대신 해주고 있기 때문이다. 이것이 IoC 라는 개념이다.

장점

• 객체 간 결합도를 낮춘다.

• 유연한 코드 작성 가능

• 가독성 증진

• 코드 중복 방지

• 유지 보수 용이

🐰 DI (Dependency Injection)

• 의존성 주입 이라는 의미로, 클래스 간의 의존성을 줄이기 위해 사용되는 개념이다.

• 스프링이 다른 프레임워크와 차별화되어 제공하는 의존관계 주입 기능

🐾 의존성 : 한 클래스가 다른 클래스에 의존하여 해당 클래스의 기능을 사용하거나 데이터를 받아와야 하는 상태를 말한다.

• 객체를 직접 생성하는 게 아니라 외부에서 생성한 후 주입 시켜주는 방식이다.

• 일반적으로 클래스를 설계할 때, 의존성이 높게 구성되어 있다면 코드의 재사용성이 떨어지고 테스트하기도 어려워 진다. 이런 문제를 해결하기 위해 DI는 의존성을 외부에서 관리하도록 한다. 즉, 클래스 내부에서 필요로 하는 객체를 직접 생성하는 대신, 외부에서 이를 주입받도록 한다.

구현 방법

1. 생성자 주입 (Constructor Injection)

   • 생성자를 통해 의존 관계를 주입하는 방법이다. 의존성을 객체를 생성할 때 생성자를 통해 주입한다는 말이다.

   • 객체 생성 시 1회 호출되는 것이 보장된다. 그렇기 때문에 주입받은 객체가 불변 객체여야 되거나, 반드시 객체의 주입이 필요한 경우에 강제하기 위해 사용할 수 있다. 생성자가 1개만 있을 경우 @Autowired를 생략해도 주입이 가능하다.

@Service
public class UserService {

    private UserRepository userRepository;
    private MemberService memberService;

    @Autowired
    public UserService(UserRepository userRepository, MemberService memberService) {
        this.userRepository = userRepository;
        this.memberService = memberService;
    }

}

2. 수정자 주입 (Setter Injection)

   • 필드 값을 변경하는 setter()를 통해서 의존 관계를 주입하는 방법 주입받는 객체가 변경될 가능성이 있는 경우에 사용한다. 선택적인 의존성을 사용할 때 유용하다. 상황에 따라 의존성 주입이 가능하다.

   • @Autowired로 주입할 대상이 없는 경우에는 오류가 발생한다. 주입할 대상이 없어도 동작하도록 하려면 @Autowired(required = false)를 통해 설정할 수 있다.

@Service
public class UserService {

    private UserRepository userRepository;
    private MemberService memberService;

    @Autowired
    public void setUserRepository(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    @Autowired
    public void setMemberService(MemberService memberService) {
        this.memberService = memberService;
    }
}

생성자 주입을 사용해야 하는 이유

최근에 Spring을 포함한 DI 프레임워크의 대부분이 생성자 주입을 권장하고 있다.

• 수정자 주입의 단점

  • public으로 구현하기 때문에, 관계를 주입받는 객체의 변경 가능성을 열어둔다. 이런 이유 때문에, 수정자 주입 방식은 주입 받는 객체가 변경될 필요성이 있을 때만 사용해야 한다.

  • 변경의 가능성을 열어두면, 다른 곳에서 임의로 객체를 변경할 수 있기 때문에 에러가 발생할 위험이 높다.

• 객체의 불변성을 확보 🐾 객체의 불변성을 확보할 수 있다.

  • 객체의 생성자는, 객체 생성 시 1회만 호출된다는 게 보장되는 특징이 있다. 이 특징 덕분에 주입받은 객체가 불변 객체여야 되거나, 반드시 해당 객체의 주입이 필요한 경우에 사용한다.

  • 생성자로 한번 의존 관계를 주입하면, 생성자는 다시 호출될 일이 없기 때문에 불변 객체를 보장한다.

• 테스트 코드의 작성 🐾 테스트 코드의 작성이 용이해진다.

  • @Autowired를 사용하여 스프링과 결합하면 테스트가 단위 테스트가 아니고, 테스트 비용이 증가할 수 있다.

  • 컴파일 시점에 객체를 주입받아 테스트 코드를 작성할 수 있으며, 주입하는 객체가 누락된 경우 컴파일 시점에 오류를 발견할 수 있다.

  • 특히 순수 자바로 작성된 테스트 코드에서는 외부 의존성을 모의(Mock) 객체로 대체하여 유닛 테스트를 더 쉽게 수행할 수 있다.

• final 키워드 작성 및 Lombok 과의 결합 🐾 final 키워드를 사용할 수 있고, Lombok과의 결합을 통해 코드를 간결하게 작성할 수 있다

  • 생성자 주입을 사용하면 필드 객체에 final 키워드를 사용할 수 있으며, 컴파일 시점에 누락된 의존성을 확일할 수 있다.

  • Lombok의 @RequiredArgsConstructor를 활용하면 간결한 코드 작성이 가능하다.

• 순환 참조 에러 방지

  • A객체가 B객체가 서로 참조하고 있을 때 발생한다.

  • 생성자 주입을 사용하면 애플리케이션 구동 시점(객체의 생성 시점)에 순환 참조 에러를 예방한다.

장점

• 모듈 간의 결합도가 낮아지고 유연성이 높아진다.

• 가독성 및 코드 중복, 유지 보수를 편하게 할 수 있게 한다.

IoC와 DI

• 객체지향 프로그래밍의 원리를 따르며, 코드의 결합도를 낮추고 유지 보수성을 향상시키는 데 도움을 준다. 또한 테스트 용이성과 모듈화를 강화하고, 대규모 애플리케이션 개발에서 코드의 복잡성을 관리하는 데 유용하다.

참고

[Spring] DI, IoC 정리 IOC,DI 정의/장점 다양한 의존성 주입 방법과 생성자 주입을 사용해야 하는 이유

알고리즘의 성능을 나타내는 지표

• 가독성(Readability)와 다른 의미로 쓰인다. 즉, 코드가 얼마나 복잡하고 알아보기 어려운지를 의미하는 것이 아니라 불특정한 함수의 성능적인 측면에서의 복접도를 의미한다.

• 시간 복잡도 : 알고리즘의 수행 시간 분석

• 공간 복잡도 : 알고리즘의 메모리 사용량 분석

• 이때, 동일한 기능을 수행하는 알고리즘이 있다면, 일반적으로 복잡도가 낮은 알고리즘이 좋은 알고리즘이다.

🐰 시간 복잡도 (Time Complexity)

알고리즘이 작업을 완료하는 데 걸리는 시간을 나타낸다.

• 시간 복잡도가 낮다는 말은 알고리즘이 더 빠르고 효율적으로 실행된다는 것을 의미한다.

• 시간 복잡도는 여러가지 개념이 있지만 그중 worst case를 기준으로 표기하는 빅-오(Big-O) 표기법을 사용한다. 즉, 알고리즘이 작업을 완료하는 데 걸리는 최대 시간을 의미한다.

• 예를 들어, 시간 복접도가 O(n)인 알고리즘은 입력 크기(n)가 증가함에 따라 실행하는 데 더 오랜 시간이 걸리는 반면, 시간 복잡도가 O(1)인 알고리즘은 입력 크기에 상관없이 실행하는 데 동일한 시간이 걸린다.

faster O(1) < O(log n) < O(nlog n) < O(n²) < O(2ⁿ) slower

slower로 갈수록(즉, 오른쪽 방향으로 갈수록) 효율성이 떨어진다.

🐰 공간 복잡도 (Space Complexity)

알고리즘이 작업을 완료하는 데 필요한 메모리 양을 나타낸다.

• 공간 복잡도가 낮다는 말은 알고리즘이 더 효율적이고 더 적은 리소스를 사용한다는 것을 의미한다.

• 알고리즘이 입력 크기의 함수로서 요구하는 메모리의 양으로 측정된다.

• 예를 들어, 공간 복잡도가 O(n)인 알고리즘은 입력 크기가 증가함에 따라 더 많은 메모리를 필요로 하는 반면, 공간 복잡도가 O(1)인 알고리즘은 입력 크기에 관계없이 동일한 양의 메모리를 필요로 한다.

정리

• 알고리즘을 설계하고 분석할 때 시간 복잡도와 공간 복잡도 모두 중요한 고려 사항이라는 점에 유의해야 한다. 시간 복잡도가 낮은 알고리즘은 실행하는 데 더 많은 메모리가 필요할 수 있지만 공간 복잡도가 낮은 알고리즘은 실행하는 데 더 오래 걸릴 수 있다. 이 두 요소 사이의 균형은 알고리즘의 특정 요구 사항과 사용 가능한 리소스에 따라 달라진다. 최근에는 하드웨어 메모리 용량이 많이 좋아졌기 때문에 시간 복잡도가 우선시 된다.

참고

혼잣말하는 개발자 시간 복잡도와 공간 복잡도

🐰 CORS

• 교차 출처 리소스 공유라는 뜻으로, 브라우저가 보안을 위해 기존 출처의 리소스와 다른 출저의 리소스 접근을 허용/거부하는 정책 입니다. 허용 방안으로는 simple request, preflight request, credential request가 있는데, 대부분 preflight 방법으로 허용합니다. preflight 방법은 클라이언트가 예비 요청을 통해 받아온 서버의 Access-Control-Allow-Origin 헤더의 정보와 본 요청의 origin 헤더를 비교해 같은 출처라면 허용하는 방법입니다.

• 어떤 자연수를 제곱했을 때 나오는 정수를 제곱수라고 합니다. 정수 n이 매개변수로 주어질 때, n이 제곱수라면 1을 아니라면 2를 return하도록 solution 함수를 완성해주세요.

제한사항 1 ≤ n ≤ 1,000,000

입출력 예 n result 144 1 976 2

입출력 예 #1

• 144는 12의 제곱이므로 제곱수입니다. 따라서 1을 return합니다.

입출력 예 #2

• 976은 제곱수가 아닙니다. 따라서 2를 return합니다.

내 풀이

class Solution {
    public int solution(int n) {

        if((double)Math.sqrt(n) % 1 == 0) {
            return 1;
        }
        return 2;
    }
}

교차 출처 리소스 공유 (Cross-Origin Resource Sharing)

• 추가 HTTP 헤더를 사용하여, 한 출처에서 실행중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제

• 웹 애플리케이션은 리소스가 자신의 출처와 다를 때 교차 출처 HTTP 요청을 실행한다.

• 쉽게말해 웹사이트가 다른 웹사이트의 자원을 사용할 수 있도록 허용하는 체제이다.

  • 예를 들어, A.com이라는 웹사이트에서 B.com이라는 웹사이트의 이미지를 사용하려면 B.com에서 CORS를 설정해야 한다. 이렇게 하면 브라우저가 A.com에서 B.com의 이미지를 안전하게 가져올 수 있다.

출처(Origin)

• 출처는 Protocol, Host 그리고 Port까지 모두 합친 것을 의미한다. 브라우저의 개발자 도구 콘솔에서 Location 객체가 가지고 있는 origin 프로퍼티에 접근하여 현재 출처를 알아낼 수도 있다.

작동 원리

• 다른 출처의 리소스를 요청할 때 HTTP 프로토콜을 사용하여 요청을 보내게 되는데, 이때 브라우저는 요청헤더에 Origin 이라는 필드에 요청을 보내는 출처를 함께 담아서 보낸다.

Origin: https://velog.io

• 이후 서버가 요청에 대한 응답을 할 때 응답 헤더의 Access-Countrol-Allow-ORigin 이라는 값에 접근이 허용된 출처를 알려주고 응답을 받은 브라우저는 클라이언트가 보낸 요청의 Origin 과 서버가 보내준 응답을 비교하여 이 응답이 유효한 응답인지 아닌지 결정한다.

• CORS 요청에는 단순 요청과 실행 전 요청 두 가지 유형이 있다.

1. 단순 요청 (Simple Request)

• 예비 요청(Prefilght)을 생략하고 바로 서버에 본 요청을 한후, 서버가 이에 대한 응답의 헤더에 Access-Control-Allow-Origin 헤더를 보내주면 브라우저가 CORS 정책 위반 여부를 검사하는 검사하는 방식이다.

• 단순요청은 특정한 조건을 만족하는 경우에만 성립할 수 있다.

  1. 요청 메서드(Method)는 GET, HEAD, POST 중 하나여야 한다.

  2. Content-Type 헤더가 application/x-www-form-urlencoded, multipart/form-data, text/plain중 하나여야한다. 아닐 경우 예비 요청으로 동작된다.

  3. Accept, Accept-Language, Content-Language, Content-Type, DPR, Downlink, Save-Data, Viewport-Width, Width 헤더일 경우 에만 적용된다.

• 예를 들어, 브라우저에서 웹사이트 A에서 웹사이트 B로 데이터를 가져오려고 할 때, 위의 조건을 모두 만족하면 해당 요청은 "단순 요청"으로 간주되어 별도의 사전 요청(예비 요청)없이 바로 실행된다.

2. 예비 요청 (Preflight Request)

• 예비 요청과 본 요청으로 나누어서 서버로 전송한다. 이때 브라우저가 예비요청을 보내는 것을 Preflight라고 부르며 예비요청은 OPTIONS 메소드를 사용한다. 예비 요청의 역할은 본 요청을 보내기전 브라우저가 요청을 보내는 것이 안전한지 확인하는 것이다.

• 자바스크립트의 fetch API를 통해 브라우저에게 리소스를 받아오게 하면 브라우저는 서버로 예비요청을 먼저 보내고 서버는 이 예비요청에 대한 응답으로 어떤 것을 허용하고 어떤것을 금지하고 있는지에 대한 정보를 담아서 브라우저로 다시 보내준다.

• 이후 브라우저는 보낸 요청과 서버가 응답해준 정책을 비교하여 해당 요청이 안전한지 확인하고 본 요청을 보내게 된다. 이후 서버가 본 요청에 대한 응답을 하면 최종적으로 이 응답 데이터를 자바스립트로 넘겨준다.

3. 인증된 요청 (Credentialed Request)

• 다른 출처간 통신에서 좀 더 보안을 강화하고 싶을 때 사용한다.

• 기본적으로 제공하는 리소스 요청 API인 XMLHttpRequest 또는 fetch는 별도의 옵션 없이 브라우저의 쿠키 정보나 인증과 관련된 헤더를 함부로 요청에 담지 않는다. 이때 요청에 인증과 관련되 정보를 담을 수 있게 해주는 옵션이 credentials옵션이다.

• 만약 same-origin 이나 include와 같은 옵션을 사용하여 리소스 요청에 인증 정보가 포함된다면, 브라우저는 다른 출처의 리소를 요청할 때 Access-Control-Allow-Origin만 확인하는 것이 아니라 다른 조건을 추가로 검사한다.

• 요청에 인증정보가 담겨있는 상태에서 다른 출처의 리소스를 요청하게 되면 브라우저는 CORS정책 위반 여부를 검사하는 룰에 다음 두가지를 추가하게 된다.

• Access-Control-Allow-Origin 에는 모든 요청을 허용하는*을 사용할 수 없으며, 명시적인 URL이어야 한다 응답 헤더에는 반드시 Access-Control-Allow-Credentials:true가 존재해야 한다

🐾 허용하는 방법

• 서버 측에서 적절한 설정을 해주어야 한다.

• 서버에서 Access-Control-Allow-Origin 헤더에 허용할 출처를 기재해서 클라이언트에 응답하면 된다.

Access-Control-Allow-Origin: https://example.com

• 이렇게 하면 https://example.com이라는 출처에서 오는 요청이 허용된다.

🐾 Access-Control-Allow-Origin 헤더 세팅

• JSP / Servlet

  import javax.servlet.*;
  

public class CORSInterceptor implements Filter {

private static final String[] allowedOrigins = {
        "http://localhost:3000", "http://localhost:5500", "http://localhost:5501",
        "http://127.0.0.1:3000", "http://127.0.0.1:5500", "http://127.0.0.1:5501"
};

@Override
public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {
    HttpServletRequest request = (HttpServletRequest) servletRequest;

    String requestOrigin = request.getHeader("Origin");
    if(isAllowedOrigin(requestOrigin)) {
        // Authorize the origin, all headers, and all methods
        ((HttpServletResponse) servletResponse).addHeader("Access-Control-Allow-Origin", requestOrigin);
        ((HttpServletResponse) servletResponse).addHeader("Access-Control-Allow-Headers", "*");
        ((HttpServletResponse) servletResponse).addHeader("Access-Control-Allow-Methods",
                "GET, OPTIONS, HEAD, PUT, POST, DELETE");

        HttpServletResponse resp = (HttpServletResponse) servletResponse;

        // CORS handshake (pre-flight request)
        if (request.getMethod().equals("OPTIONS")) {
            resp.setStatus(HttpServletResponse.SC_ACCEPTED);
            return;
        }
    }
    // pass the request along the filter chain
    filterChain.doFilter(request, servletResponse);
}

private boolean isAllowedOrigin(String origin){
    for (String allowedOrigin : allowedOrigins) {
        if(origin.equals(allowedOrigin)) return true;
    }
    return false;
}

}

- Spring 
```java
// 스프링 서버 전역적으로 CORS 설정
@Configuration
public class WebConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
            .allowedOrigins("http://localhost:8080", "http://localhost:8081") // 허용할 출처
            .allowedMethods("GET", "POST") // 허용할 HTTP method
            .allowCredentials(true) // 쿠키 인증 요청 허용
            .maxAge(3000) // 원하는 시간만큼 pre-flight 리퀘스트를 캐싱
    }
}

// 특정 컨트롤러에만 CORS 적용하고 싶을때.
@Controller
@CrossOrigin(origins = "*", methods = RequestMethod.GET) 
public class customController {

    // 특정 메소드에만 CORS 적용 가능
    @GetMapping("/url")  
    @CrossOrigin(origins = "*", methods = RequestMethod.GET) 
    @ResponseBody
    public List<Object> findAll(){
        return service.getAll();
    }
}

참고

교차 출처 리소스 공유 (CORS)

[WEB] CORS 개념 정리

악명 높은 CORS 개념 & 해결법 - 정리 끝판왕

• 문자열 str1, str2가 매개변수로 주어집니다. str1 안에 str2가 있다면 1을 없다면 2를 return하도록 solution 함수를 완성해주세요.

제한사항 1 ≤ str1의 길이 ≤ 100 1 ≤ str2의 길이 ≤ 100 문자열은 알파벳 대문자, 소문자, 숫자로 구성되어 있습니다.

입출력 예 str1 str2 result "ab6CDE443fgh22iJKlmn1o" "6CD" 1 "ppprrrogrammers" "pppp" 2 "AbcAbcA" "AAA" 2

입출력 예 #1

• "ab6CDE443fgh22iJKlmn1o" str1에 str2가 존재하므로 1을 return합니다.

입출력 예 #2

• "ppprrrogrammers" str1에 str2가 없으므로 2를 return합니다.

입출력 예 #3

• "AbcAbcA" str1에 str2가 없으므로 2를 return합니다.

내 풀이

class Solution {
    public int solution(String str1, String str2) {

            if(str1.contains(str2)) {
                return 1;
            }

        return 2;
    }
}

• 비교하고 정리하는 과정에서 내가 두리뭉실하게만 알고 있었던 어느 상황에서 써야 더 효율적으로 사용할 수 있는지 시간복잡도를 통해서 보니 확실히 비교할 수 있었다.

• 비교 정리

  • 배열은 정적 자료구조로, 크기를 미리 정해놓고 연속된 메모리에 요소들을 저장합니다. 이로 인해 메모리 상에서 효율적으로 관리되며, 인덱스를 통해 빠르게 요소에 접근할 수 있습니다. 또한 요소를 추가하거나 삭제할 때에는 다른 요소들을 이동시켜야 하므로 O(n) 시간이 걸립니다. 반면, 연결 리스트는 동적 자료구조로, 동적으로 크기가 조절될 수 있습니다. 각 요소는 독립적인 노드로 구성되어 있고, 노드들은 포인터를 통해 서로 연결되어 있습니다. 요소를 추가하거나 삭제할 때에는 단순히 노드의 연결만 조정하면 되기 때문에 O(1) 시간이 걸립니다. 다만 리스트 앞이나 중간에 요소를 추가/삭제하는 경우 노드를 찾는 시간이 추가적으로 필요할 수 있습니다. 결론적으로, 배열은 데이터의 접근, 탐색할 때 유용하고 연결 리스트는 데이터의 추가, 삭제할 때 유용하게 사용됩니다.

배열과 연결 리스트 비교

🐰 플러스 과제

• 이 중 Error 메시지 관리와 예외 공통화 처리를 이런식으로 하는게 맞는지 좀 더 효율적인 방법은 없는지에 대해 고민을 많이하고 검색도 많이했지만 내가 할 수 있는 최선이였다. 이 부분에 대해서는 튜터님에게 물어보기!!

• PostServiceImpl

  public Post findPost(Long id) {
        return postRepository.findById(id).orElseThrow(
                () -> new NotFoundException(messageSource.getMessage(
                        "not.found.post",
                        null,
                        "Not Found Post",
                        Locale.getDefault()
                ))
        );
    }

• GlobalExceptionHandler

@ExceptionHandler({NotFoundException.class})
    public ResponseEntity<StatusResponseDto> notFoundProductExceptionHandler(NotFoundException ex) {
        StatusResponseDto statusResponseDto = new StatusResponseDto(ex.getMessage(), HttpStatus.NOT_FOUND.value());
        return new ResponseEntity<>(
                statusResponseDto,
                HttpStatus.NOT_FOUND
        );
    }

• NotFoundException

public class NotFoundException extends RuntimeException{
    public NotFoundException(String message) {
        super(message);
    }
}

• messages.properties

  not.found.post = 해당 게시글이 존재하지 않습니다.
  

//나머지 부분 생략

```

🐰 알고리즘

1. [프로그래머스] 삼각형의 완성조건 (1) Java

2. [프로그래머스] 최댓값 만들기 (1) Java

   • 삼각형의 완성조건과 최댓값 만들기는 둘 다 비슷한 결이라서 Arrays.sort()를 이용해 문제해결을 했다.

3. [프로그래머스] 숨어있는 숫자의 덧셈 (1) Java

   • 지금까지 사용한 함수를 적절히 사용해서 풀어야 하는 느낌이였다. 첫 시도때는 string을 정수로 바꿀 생각만 했었다. 그 결과, 입출력 예 #1 에서 1+2+3+4가 아닌 1234+1234+... 이런식으로 계속 string의 길이만큼 더해져서 4936 가 나왔다...
   • 최종적으로 split을 이용해 하나 하나 자르고 배열에 저장한뒤 향상된 포문에서 Integer.parseInt()를 사용해 정수로 바꿔 더해줬다.

• 문자열 my_string이 매개변수로 주어집니다. my_string안의 모든 자연수들의 합을 return하도록 solution 함수를 완성해주세요.

제한사항 1 ≤ my_string의 길이 ≤ 1,000 my_string은 소문자, 대문자 그리고 한자리 자연수로만 구성되어있습니다.

입출력 예 my_string result "aAb1B2cC34oOp" 10 "1a2b3c4d123" 16

입출력 예 #1

• "aAb1B2cC34oOp"안의 한자리 자연수는 1, 2, 3, 4 입니다. 따라서 1 + 2 + 3 + 4 = 10 을 return합니다.

입출력 예 #2

• "1a2b3c4d123Z"안의 한자리 자연수는 1, 2, 3, 4, 1, 2, 3 입니다. 따라서 1 + 2 + 3 + 4 + 1 + 2 + 3 = 16 을 return합니다.

유의사항

• 연속된 숫자도 각각 한 자리 숫자로 취급합니다.

내 풀이

• 첫 시도

  class Solution {
    public int solution(String my_string) {
        int answer = 0;
  
        my_string = my_string.replaceAll("[a-zA-Z]", "");
        int num = Integer.parseInt(my_string);
  
        for (int i = 0; i < my_string.length(); i++) {
            answer += num;
        }
  
        return answer;
    }
  }

• 최종 풀이

  class Solution {
    public int solution(String my_string) {
        int answer = 0;
  
        my_string = my_string.replaceAll("[a-zA-Z]", "");
        String[] string = my_string.split("");
  
        for(String i : string) {
            answer += Integer.parseInt(i);
        }
  
        return answer;
    }
  }

🐾 첫 시도때는 string을 정수로 바꿀 생각만 했었다. 그 결과, 입출력 예 #1 에서 1+2+3+4가 아닌 1234+1234+... 이런식으로 계속 string의 길이만큼 더해져서 4936 가 나왔다...정신차려

🐾 여러 단계를 걸쳤지만 생략하고 최종적으로 split을 이용해 하나 하나 자르고 배열에 저장한뒤 향상된 포문에서 Integer.parseInt()를 사용해 정수로 바꿔 더해줬다. 성공!!

• 정수 배열 numbers가 매개변수로 주어집니다. numbers의 원소 중 두 개를 곱해 만들 수 있는 최댓값을 return하도록 solution 함수를 완성해주세요.

제한사항 0 ≤ numbers의 원소 ≤ 10,000 2 ≤ numbers의 길이 ≤ 100

입출력 예 numbers result [1, 2, 3, 4, 5] 20 [0, 31, 24, 10, 1, 9] 744

입출력 예 #1

• 두 수의 곱중 최댓값은 4 * 5 = 20 입니다.

입출력 예 #1

• 두 수의 곱중 최댓값은 31 * 24 = 744 입니다.

내 풀이

import java.util.*;

class Solution {
    public int solution(int[] numbers) {

        Arrays.sort(numbers);

        return numbers[numbers.length-1] * numbers[numbers.length-2];
    }
}