* 추상클래스와 인터페이스

   - 설명을 예시를 들어 쉽게 해주시는 얄코님의 강의에서 추상클래스는 물려받는 혈통 가문과 같이 딱 하나만 받을 수 있는 나의 정체성이고, 인터페이스는 여러개를 받을 수있는 자격증과 같은 개념이라고 했다. 

   - 또한 아래 참고에 적어놓은 블로그에서는 "극단적으로 동일한 목적 하에 동일한 기능을 수행하게끔 강제하는 것이 역할이자 개념"이라고 정의하고있다.

    - 즉, 어떠한 클래스들이 운전면허증, 복어조리자격증, 주조자격증 등과 같이 어떠한 동일한 목적을 가지고 동일한 기능을 수행할 수 있도록 그런 기능을 모아놓은 인터페이스를 적용하는 것이다.

* 인터페이스의 특징

    - 다중상속 가능 (자격증은 100개라도 가질 수 있다..)

    - 생성자 사용 불가: 인터페이스는 메서드의 명세를 정의하고 구현을 강제하기 위한 것이며, 실제 객체 생성은 인터페이스를 구현한 클래스에서 이루어진다.

* 인터페이스에 사용되는 4가지

    - 상수 : 필드는 무조건 상수로 선언해야한다. final 키워드를 빼도 된다. 어차피 무조건 상수이니까!

    - 클래스 메서드: 재정의가 불가능한 구현 메서드. 무조건 사용!!

    - 디폴트 메서드: 재정의가 가능한 구현 메서드. 사용하던 말던 괜찮다

    - 추상 메서드 : 메서드 이름만 정의되어있는 추상메서드. abstract 키워드는 빼도 된다. 

* 구상 메서드가 추가된 이유

    - 인터페이스 내에서 클래스, 디폴트 메서드는 자바8에서 추가된 기능이다. 

    - A라는 클래스를 사용하고 있는데 b라는 기능이 추가로 나왔을 때 이 b라는 기능을 추상메서드로 추가하게되면 A클래스를 사용하고 있는 곳에서는 모두 b라는 기능을 오버라이드 해주어야한다... 이런 문제를 해결할 수있다.

* static 메서드와 default 메서드의 차이

    - static은 이미 구상되어있는 메서드이지만 무조건! 이대로 사용해야하고 수정할 수없다.

    - default는 이미 구상되어있는 메서드이지만 불가피하게 변경을 해야할 때 재정의를 해서 사용할 수 있다.

*Observer pattern

- 옵저버패턴은 객체 간의 일대다 의존관계를 정의하는 패턴이다. 주로 한 객체(subject)의 상태가 변경될 때 이와 관련된 다른 객체들에게 자동으로 알림을 전달할 떄 사용된다. 

=> 객체간의 결합도를 낮추고 유연성을 향상시킴.

- Subject: 상태를 관찰하고 관찰자들에게 알림을 보내는 주체. 관찰자인 옵저버를 등록하고 해제하는 메서드를 가지고 있어야함

- Observer: 관찰자는 Subject의 상태 변화를 감지하고 이에 따른 동작을 수행하는 객체. 

- 자바에서는 java.util 패키지에 Observerble 클래스와 Observer 인터페이스가 기본적으로 제공되어 이를 사용해서 구현할 수 있다!

- Observable클래스는 deprecated되어서 java.beans 패키지의 PropertyChangeSupport를 사용하는 것을 권장한다고 한다......

- 그리고 Observable이 interface가 아닌 클래스여서 커스텀해서 사용할 수 없다는 단점도  또 있다!

-> 그래서 그냥 만들어서 사용하는게 낫지 않을까..~ 

* 공부하며 만들어본 팀 채팅 알람 기능!

- ChatSubject라는 subject interface는 observer를 등록하고 해제하고 알림을 실행할 수 있는 메서드를 가지고 있다.

- TeamChat 클래스는 ChatSubject를 implements한 클래스이고 주요 동작인 sendMessage() 를 추가해서 캡슐화를 했다.

- ChatObserver는 update()기능을 가지고 있는 interface이다.

- TeamMember는 ChatObserver를 implements한 클래스이다. 



TeamChat 객체를 만들어서 TeamMember들을 넣어놓으면 TeamMember는 TeamChat에서 메세지가 오는지 감지할 수 있다.

메세지가 오는 것을 전달 전달받으면 각각 메세지를 전달받을 수 있다.

당연하게도 detach로 주제에서 member를 빼면 상태 변화를 감지할 수 없다.

** 참고자료 **

- 인프런 얄코 제대로 파는 자바  

-https://velog.io/@hanna2100/%EB%94%94%EC%9E%90%EC%9D%B8%ED%8C%A8%ED%84%B4-2.-%EC%98%B5%EC%A0%80%EB%B2%84-%ED%8C%A8%ED%84%B4-%EA%B0%9C%EB%85%90%EA%B3%BC-%EC%98%88%EC%A0%9C-observer-pattern

- https://limkydev.tistory.com/197

3.  사용자 정의 어노테이션

- 메타 어노테이션을 활용해서 내가 필요한 어노테이션을 만드는 것

@Retention(용도)
@Target(범위) // 여러 개를 동시에 선언 가능(배열이기 떄문에 중괄호로 묶는다)
...
public @Interface AnnotationName {
	T methodName();
	...
}

-  @Retention과 @Target은 사용해주는 것이 코드의 가독성과 유지보수성을 향상시키고, 어노테이션의 사용 방법을 명확히한다.

-  효율이 나지 않을 수 있기 때문에 필요한 때에만 사용하는 것이 좋다.

https://ggop-n.tistory.com/88

https://seongeun-it.tistory.com/142

https://blog.naver.com/kang594/39704853

1. 자바에서  nullPointException을 만나는 이유

• - null을 리턴하고 null 체크를 안 해줘서

2. 메서드에서 값을 제대로 리턴할 수 없을 때 사용하는 방법

• - 예외처리
• - null 리턴
• - optional 리턴

3. Optional이란?

• -  값을 0개 또는 1개 담을 수 있는 컨테이너
• - 래퍼클래스
• - 리턴되는 값이 null이 올 수도 있다는 것을 명시적으로 알려줌.

4. 사용

• -  래퍼클래스이기 때문에 primitive타입을 담을 때에는 OptionalInt나 OptionalLong을 사용해야 박싱 언박싱을 피해서 성능을 살릴 수 있다.
• - 리턴값에서만 사용한다. 
•   1) 파라미터로 받을 때에는 굳이 한 번더 optional에서 null체크를 해주어야한다. null일 때 isPresent를 사용하면 바로 nullPointException
• -> argument를 넘길때는 optional로 감싸지 않고 보내고 파라미터에는 optional로 받는 문제
•   2) 인스턴스 필드에 Optional을 사용하지 않는다.  get 메서드에서 Optional로 리턴해줄 수 있음 . optional.of(value) 또는 optional.nullable(value) -> null일 가능성이 있을 때는 nullable로 리턴해야 nullPointException이 안 난다. 
•   3) null을 리턴하지 말자. -> Optional.empty()를 리턴
•  
• - Collection, Map, Stream, Array, Oprional과 같은 컨테이너 타입의 인스턴스들은 Optional로 감싸지 않는다. 그 자체로 null인지 아닌지 알 수 있기 때문에 필요가 없음.

5. 메서드

• - isPresent(), isEmpty()-이건 11부터 
• - get() -> isPresent() 등으로 확인 하지 않고 실행할때 null이면 noSuchElementException 발생. 근데 가급적이면 아래의 메서드들로 실행하면 좋다
• - ifPresent()  -> 만약에 값이 있으면 어디에 담지 않고 바로 람다로 ~실행
• - orElse() 값이 있으면 가져오고 없는 경우에는 ~~를 리턴하라 (있던 없던 연산 무조건 실행)
• - orElseGet() 값이 있으면 가져오고 없는 경우에 ~~를 하라.
• - orElseThrow() 값이 있으면 가졍고 없는 경우 에러를 던져라.
• - Optional filter(Predicate) 값 걸러내기
• - Optional Map(Function) 값 변환하기
• - Optional flatMap(Function) -> map으로 꺼내온 타입 자체가 Optional이면 Optioanal 안에  Optional이 있는 것이다. 이러면 데이터를 까야한다. 그런데 flatMap을 쓰면 이미 과정에서 한 번 꺼내줌
•  

- 참조

더 자바 - JAVA8 (백기선 인프런강의)

1. 스트림이란?

     - 연속된 데이터를 처리하는 오퍼레이션의 모음. (파이프라인안에서 순서대로 일을 처리하고 빠져나가는 모양)

     -  데이터가 아니고 컬렉션과 같은 데이터를 소스로 사용하여 처리를 하는 기능.

     - 처리하는 과정에서 원본 데이터가 변경되는 것이 아니다.

2. 구성요소

• - 스트림 파이프라인: 0 또는 다수의 중개 오퍼레이션과 한개의 종료 오퍼레이션으로 구성한다. 
• - 종료 오퍼레이션이 오지 않으면 중개오퍼레이션은 실행되지 않음
•     - 중개 오퍼레이션: stream을 리턴한다. filter, map, limit, skip, sorted 등. 
•     - 종료 오퍼레이션: stream을 리턴하지 않는다. collect, allMatch, count, forEach 등

3. 장점

    - for, forEach같은 반복문을 사용하는 것보다 코드가 간결해지고, 각 단계가 명확하게 표현된다.

    - 병렬 처리를 쉽게할 수 있는 기능을 제공해서 성능을 향상시킬 수 있다. 

    - 필요할 때만 요소를 처리하므로, 필요하지 않은 연산을 피할 수 있다. -> 성능을 최적화하는 것에 도움이 됨

    - 함수형 프로그래밍 개념을 적용해서 그의 장점인 코드 재사용성은 높아지고 부작용은 줄일 수 있다. 

4. 단점

    - 추가적인 객체 생성과 메서드 호출로 인한 성능 오버헤드가 발생할 수 있다. 

예)

     public class Main {
    public static void main(String[] args) {
        List<String> fruits = new ArrayList<>();
        fruits.add("apple");
        fruits.add("banana");
        fruits.add("orange");
        fruits.stream().map(String::length).forEach(System.out::println);
    }
}

    - 함수형 프로그래밍의 개념과 메서드 체인 연산 등의 개념을 이해해야 잘 사용할 수 있다.

    - for문보다 속도는 느리다. (for문은 인덱스 기반이다. 메모리 접근이라 빠름 / stream은 jvm이 이것저것 처리해줘야하는 것들이 많아 실행시 느림)

5. 사용시 주의점

    - 스트림을 재사용하면 안된다. 리턴받은 Stream 객체를 다시 스트림으로 처리하면 illegalStateException이 발생함.

    - 이터레이터를 사용하여 반복을 했을 때 빠져나올 수 없는 경우에는 무한 스트림이 생성될 수 있다. 

    - 스트림을 이용하면서 람다 또는 메서드 참조를 사용하는 경우에는 지역번수에 접근할 수 없다. final 변수만 사용 가능.

스프링부트 스터디를 하면서 내 프로젝트를 만들어보고싶었다!! 

그래서 시작한 즐농 프로젝트. ㅋㅋ 

1. 인텔리제이에 스프링 프로젝트를 만들기.

- 내가 쓰고싶은 디펜던시들을 욕심부려서 처음부터 다 넣어놨는데 db를 연결해주지 않은채로 jpa를 넣어놔서 이런 오류가 발생했다!

얼른 주석처리 했음.

Description: Failed to configure a DataSource: 'url' attribute is not specified and no embedded datasource could be configured. Reason: Failed to determine a suitable driver class

- mysql db연결을 했는데 계속 로그인 창이 나왔다. 처음보는 현상이고 이 전에 스터디했던 스프링부트 프로젝트 파일이 뭔가 충돌이 난건가 싶은 생각에 혼란스러웠다.. ㅋㅋ 검색해보니까  오라클 포트와 겹쳐서 그렇게 된다는 사람이 많았는데,, 난 오라클을 설치하지 않았다. 어쨋든 포트번호 문제인가 생각해서 application.properties에서 포트를 계속 변경해보았지만 똑같은 현상이 나타났다.. 다시 검색해본 결과 security가 막고있다는 것 같다. 다시 시큐리티 관련된 디팬던시들을 주석처리했다... 성공! ㅠㅠ 큰 교훈을 얻었다....

- 테스트! 포스트맨으로 post요청을 보내서 데이터를 넣어봤고 db에 잘 들어갔다.

2. Vue3 넣기 

- 회사에서는 vue2로 프로젝트를 진행하는데 vue2는 더이상 지원을 해주지 않는다고 해서,, 나는 vue3로 프로젝트를 진행해보려고 한다. 

  이벤트버스라던가 그런 것들이 없어졌던 것 같은데 공부하면서 진행하면 될 듯...

- vue는 프로젝트를 따로 만들어서 하지않고 src 폴더에 생성했다.

- vue는 8080/ springboot는 9000으로 포트를 변경하고 프록시 설정까지 했다.

- vue를 연동하는 과정에서 계속 웹팩 오류로 서버를 돌릴 수 없었는데, 이 오류는 웹팩 버전 문제였다. 업데이트 해주니까 성공!

- 또, 한 번에 프론트와 백엔드를 빌드할 수 있도록 설정을 해주는데 계속 오류가 났다... 이때는 정말 화가 많이 났다.....

  어쨌든 검색을 해본 결과 moowork이 더이상 사용이 안되는 듯. 다른 플러그인으로 변경했다. 

3. git & github 연결

- 회사에서 깃을 안 써서 처음으로 깃을 연동해봤다. 이제 회사에도 깃을 연동해야겠다 하하하하하

- 프로젝트에 깃을 설정하고, 소스트리도 연동하고, 깃허브 리포짓토리도 생성해서 연동했다~!

- 이게 되는 건지 안되는건지 모르겠어서 아무 파일이나 만들어서 커밋해봤는데 다시 보니까 컨트롤러 이름을 소문자로 시작했다 ㅠㅠㅋㅋ 어쩐지 잘 된다 싶었다...

프로젝트 설정은 어느정도 마무리 된 것 같다 ~~!! 

---------------------------------------------------------------------------------------------------------------------

---------------------------------------------------------------------------------------------------------------------

참고

https://deockstory.tistory.com/26

https://github.com/node-gradle/gradle-node-plugin/blob/7.0.1/docs/usage.md

범위 : CI/CD 도입하기

CI(Continuous Integration)

- 지속적 통합 = 빌드와 테스트를 자동화하는 과정

- 변경 사항을 자동으로 테스트해 앱에 문제가 없다는 것을 보장한다.

- 코드를 정기적으로 빌드하고 테스트 해서 여러 명이 동시에 작업을 하는 경우도 충돌을 방지하고 모니터링 할 수 있다.

- 코드 변경 사항이 코드 저장소에 업로드되면 CI를 시작하고, CI 도중 문제가 생기면 실패한다. -> 코드의 오류를 쉽게 파악 가능

CD(Continuous Delivery or Continuous Deployment)

- CI 작업을 끝낸 다음 실행하는 작업

- 지속적 제공, 지속적 배포라는 의미를 가진다.

- 배포 준비가 된 코드를 자동으로 서버에 배포하는 작업을 자동화 한 것.

- 빌드와 테스트를 성공적으로 진행했을 때 깃허브와 같은 코드 저장소에 자동으로 업로드 한다. -> 최소한의 노력으로 코드 배포를 쉽게 하는 것이 목표

- 성공적으로 병합한 코드 내역을 AWS와 같은 배포 환경으로 보냄. 실무에서는 릴리스라고 한다. 

- 개발자가 애플리케이션에 변경 사항을 커밋한 후 몇 분 이내에 애플리케이션이 자동으로 배포되어 적용된다. 

깃과 깃허브

- 깃: 코드를 저장하고 관리할 수 있는 시스템. 여러 명이 동시에 작업할 수 있다. -> 병렬 개발이 가능함

- 깃허브: 깃과 연동해 작업한 코드를 저장할 수 있는 서비스 

  ( 깃허브 외에 깃과 연동된 오픈소스 저장소는 깃랩, 비트버킷, 타라볼트 등이 있다.)

오마이갓.! 

스터디를 완주했다!!!

새해 복 많이 받으세요 ~~~~~!~!~!~!!

범위: 11장 AWS에 배포하기

다른 PC에서 내가 만든 서비스를 접속하게 할 수 있는 방법

1. 서버용 PC를 구매해서 배포

    - 공간, 설치, 유지보수가 매우 복잡함

2. AWS와 같은 클라우드 컴퓨팅 서비스를 이용하여 배포

    - 공간, 설치, 유지보수가 편리함

    - but 서비스 사용이 복잡한 관계로 공부를 더 해야한다. 

AWS(Amazon Web Services)

- 아마존에서 제공하는 클라우드 컴퓨팅 플랫폼을 구성하는 원격 컴퓨팅 서비스(웹 서비스라고도 함) 모음

- 컴퓨팅 서비스, 네트워크 서비스, 데이터베이스 서비스, 스토리지 서비스 등 다양한 서비스를 제공한다.

AWS에서 배포하기 위해 설정할 것들.

- AWS 상에서 서버를 구성(= AWS 안에서 가상 PC를 마련하는 것)하고, 그 외 많은 서비스를 직접 생성

- EC2(Elastic Compute Cloud): 가상의 PC, 즉 서버 한 대를 임대하는 서비스. 프로그램의 사용자가 많아지면 여러대의 EC2를 사용한다.

- 오토 스케일링 그룹: 사용자가 많을 때, 적을 때 모두 많은 EC2를 사용하면 낭비가 생김. 오토 스케일링 그룹이 사용자의 요청 횟수에 따라 EC2를 늘리거나 줄여서 조절해준다.

- 로드 밸런서: 요청들이 한 경로로에만 들어오면 부하가 생길 수 있다. 로드 밸런서가 요청을 분산시켜준다. 로드 밸런서를 만들 때 요청을 어디에 분산시킬지 그룹을 정해야하는데 이는 대상 그룹(target group)이라고 한다.

- 데이터 저장소: DB도 클라우드에 올려야한다. AWS에서는 RDS, Redshift, DocumentDB, ElasticCache 등이 있다. 

- 이외에도 많은 서비스를 설정해야 서버를 구축할 수 있다. => 일래스틱 빈스토크가 출시되어 조금 더 편하게 설정할 수 있다.

- 일래스틱 빈스토크: 위의 내용들을 한 번에 설정하는 서비스. 서버 업로드용 코드만 작성해도 서버를 쉽게 올릴 수 있고, 그 외의 기능들은 메뉴 안에 직접 구성하거나 설정 파일로 자동 처리할 수 있다. 

범위 10장 - OAuth2로 로그인/로그아웃 구현하기

OAuth 용어

- 리소스 오너: 개별 사용자로 리소스 서버에 등록된 각 사용자

- 리소스 서버: 인증 서버의 사용자 데이터를 보유하고 있는 서버

- 인증 서버: 카카오 또는 구글과 같은 계정 서비스

- 클라이언트 애플리케이션: 인증 서버를 통해 로그인을 사용하는 어플리케이션

OAuth

- 제 3의 서비스에 계정 관리를 맡기는 프로토콜

- OAuth가 등장하기 전에는 다른 서비스의 리소스를 가져오기 위해서는 다른 사이트의 ID와 password를 직접 입력받아 저장하여 필요한 때마다 불러와서 사용하는 방식 -> 보안 등의 문제가 생겼음.

- 네이버, 구글, 카카오로 로그인하기 같은 방법

- 인증 서버에서 발급받은 토큰을 사용하여 리소스 서버에 리소스 오너의 정보를 요청하고 응답받아 사용할 수 있음.

  1) 권한 부여 코드 승인 타입

  2) 암시적 승인 타입

  3) 리소스 소유자 암호 자격증명 승인 타입

  4) 클라이언트 자격증명 승인 타입

//  https://velog.io/@crow/OAuth-2.0-%EA%B6%8C%ED%95%9C%EB%B6%80%EC%97%AC-%EC%9C%A0%ED%98%95Grant-Type

권한 부여 코드 승인 타입

- 클라이언트가 리소스에 접근하는 데 사용하며, 권한에 접근할 수 있는 코드와 리소스 오너에 대한 액세스 토큰을 발급받는 방식

- 서비스에서 가장 중요한 정보인 사용자 데이터가 외부로 전송되지 않아 안전하고, OAuth에서 가장 잘 알려진 인증방법이다

인증 순서 (너무 헷갈린다 ㅠㅠ)

- 리소스 서버는 인증 서버에 인증 작업 위임

1. 리소스 오너 -> 애플리케이션에 권한 요청 : 스프링부트 서버가 특정 사용자 데이터에 접근하기 위해 권한 서버에 요청을 보내는 것

2. 리소스 서버 -> 리소스 오너에 데이터 접근용 권한 부여

3. 애플리케이션 -> 인증서버에 인증코드 발급 

4. 애플리케이션 -> 인증 서버에 액세스 토큰으로 발급

5. 애플리케이션 -> 리소스 서버에 액세스 토큰으로 데이터에 접근

(

카카오로 로그인 예시

- 사용자가 게임 앱에서 카카오 로그인을 선택.

- 클라이언트 애플리케이션은 카카오 계정 서비스로 리다이렉트되어 사용자 인증 진행.

- 인증 서버는 사용자를 인증하고, 클라이언트 애플리케이션에게 액세스 토큰을 제공.

- 클라이언트 애플리케이션은 액세스 토큰을 사용하여 카카오의 리소스 서버에 사용자 데이터를 요청.

- 리소스 서버는 액세스 토큰이 유효하면 해당 사용자의 데이터를 클라이언트 애플리케이션에 응답.

)

쿠키

- 사용자가 어떤 웹사이트를 방문했을 때 해당 웹사이트의 서버에서 사용자의 로컬 환경에 저장하는 작은 데이터

- 이전에 방문한 적이 있는지 알 수 있고, 로그인을 했었다면 그 정보도 유지할 수 있다.

- 키와 값으로 이루어져있음

- 만료기간, 도메인 등의 정보를 가지고있음

- HTTP 요청을 통해 쿠키의 특정 키에 값을 추가할 수 있다.

- 브라우저가 닫혀도 유지된다.

쿠키 추가 과정

- 브라우저에서 요청을 보낸다

- 서버에서 응답과 함께 쿠키를 설정해서 헤더와 함께 보낸다.

- 브라우저는 그걸 저장

- 같은 페이지에서 요청을 보낼 때 브라우저는 요청에 쿠키를 실어서 보낸다

=> 클라이언트에 값을 저장할 수 있어서 현재 사용자 관련 정보를 보여줄 수 있다.

(로그인 저장, 사용자의 활동과 기호를 추적하여 맞춤 서비스 제공, 장바구니 유지, 사용자 환경 설정 저장, 광고 등 가능)

!. 개인 정보 보호에 관련된 이슈가 있을 수 있음

+ 항상 헷갈리는 세가지를 비교해보기로 함 ㅋㅋ  

캐시

- 이전에 얻은 데이터의 복사본을 저장해두는 메모리나 디스크 공간

- 반복적으로 요청되는 데이터나 자주 사용되는 리소스를 저장하여 성능을 향상시키고 서버의 부하를 줄인다.

- 클라이언트 브라우저, 프록시 서버, CDN에서 관리된다.

세션

- 서버 측에서 유지되는 클라이언트와의 상태 정보를 저장하는 방법

- 사용자의 로그인 상태나 기타 중요한 정보를 서버에 저장하여 유지.

- 각 세션은 고유한 식별자로 구분된다.

- 서버측에 저장되어 클라이언트에 직접 노출되지 않음

- 사용자가 로그아웃 하거나 브라우저를 닫을때까지 유지됨