2021.07.19 (월) 인증

[kyupid]

평일 - 매일 최소 1 강의 주말 - 토,일 중 최소 1 강의

• [x] cxz5309
• [x] dnjsrud3407
• [x] dowon-ahn
• [x] hokyung-lee
• [x] kimminju
• [ ] kyupid
• [x] narafu
• [x] sablemarten
• [x] uiurihappy
• [ ] Kyle-Wi
• [ ] juvelop17

[kimminju]

2021.07.19 섹션2 build.gradle 기본

1. gradele 수정 시에 Reload 꼭 해줘야 함
2. plugins : 스프링 버전 확인 가능 / 의존관계 설정 확인 가능
3. sourceCompatibility : 11 (java 11버전)
4. dependencies(의존관계) : 스프링 부트 스타터, 테스트관련 lib
   • core , context 핵심 lib
5. mainApplication run 할때 서버가 돌아가기만 하고 아무런 반응이 없다

Tip(window 기준) 변경(run 돌릴 때 속도가 높다) file > settings > Build, Execution, Deployment > Build Tools > Gradle > Build and run using : IntelliJ IDEA Run tests using : IntelliJ IDEA

비즈니스 요구사항과 설계

1. 회원 1) 회원 기능 : 가입, 조회 2) 회원 등금 : 일반, vip 3) 회원 데이터는 자체 db구축 및 외부시스템과 연동가능(미확정)
2. 주문과 할인 정책 1) 회원 상품주문가능 2) 회원 등급에 따라 할인정책 적용 3) 할인정책은 모든 vip는 1000원 할인해주는 고정금액을 적용해달라(변경소지있음) 4) 할인정책은 변경가능성 높다. 회사의 기본할인정책 정하지 못함, 오픈직전까지 고민을 미루고 있음 최악의 경우 할인 적용안 할 수도 있다.(미확정) 5) 요구사항을 보면 회원데이터, 할인정책같은 부분은 지금 정하기 어렵다 그러나 이런정책이 결정될떄까지 개발을 무기한 기다릴 수 없다 => 인터페이스를 만들고 구현체를 언제든지 갈아끼울 수 있도록 설계 참고로, 순수 자바로 만든다(환경만 스프링부트로 진행)

회원도메인 설계

1. 회원도메인 협력관계

     호출    

   클라이언트 -> 회원서비스 -> 회원 저장소(인터페이스) (회원가입, 회원조회) - 메모리 회원저장소(일단 진행)

   • db 회원저장소
   • 외부시스템연동 회원저장소

2. 회원 클래스 다이어그램

   MemberService ↑ MemerServiceImpl -> MemberRepositoy - MemoryMemberRepositoy - DBMemberRepositoy

3. 회원 객체 다이어그램(실제 객체간의 메모리 참조 주소 값)

   • new 한 인스턴스끼리의 참조

   클라이언트 -> 회원서비스(MemerServiceImpl)-> 메모리 회원 저장소(MemoryMemberRepositoy or DBMemberRepositoy)

4. 구현체는 동적으로 결정 (클래스 다이어그램으로 판단하기 어려워서 객체 다이어그램을 참고한다.)

[sablemarten]

스프링 핵심 원리 이해2 - 객체 지향 원리 적용 새로운 할인 정책 개발 새로운 할인 정책 적용과 문제점 관심사의 분리

SOLID원칙에 맞춰서 코드 다시 짜는 과정을 가졌다. 역할과 구현에 대해서 다시 강조했다. 당분간은 이에 대한 부분을 계속해서 코드로 보여주는 예제 시간을 가질 것 같다. 실무에서 작업할 때에는 만들 때 피해서 만들었지만, 일단 연결 시켜주고 제거하고 넣어주는 과정을 겪는 것도 또 낯설었다. 아직 갈 길이 멀다.

• 추가 오늘 업무 중에 빈 기간이 생겨서 주말 보충 겸 스프링 핵심 원리 이해2 - 객체 지향 원리 적용 쭉 들음. 드디어 스프링 시작, 다이어그램 기능은 신기했음, 코드치는 템포와 설명 따라가는 게 슬슬 버겁고, 뒤에 정리하면서 다시 설명해주는데 코드 보면서 해주지 않아서 조금 연결시키면서 듣기 힘들었음. 정리지만 정리가 안 됨... 다시 들어야할듯

[narafu]

스프링 입문 - 섹션 6

• jdbc부터 jdbc템플릿, 그리고 jpa까지 진행하며 비교한다. 마이바티스를 주로 썼었지만 jpa는 처음 접했다. 세계적으로도 jpa가 더 많이 사용되는 줄 몰랐다. 일단은 입문이니, 차후에 jpa 강의를 들어야겠다 ㅎ

[dnjsrud3407]

강의명 : 스프링 핵심 원리 - 기본편

수강 회차 <싱글톤 컨테이너>

• 웹 애플리케이션과 싱글톤
• 싱글톤 패턴
• 싱글톤 컨테이너
• 싱글톤 방식의 주의점
• @Configuration과 싱글톤

요약

• 스프링 컨테이너는 빈 객체를 다 싱글톤으로 생성해서 관리해준다 : 클라이언트가 동시에 여러명이 접속하기 때문에 프로그램을 효율적으로 사용하기 위함

• 싱글톤 방식의 주의점 : 싱글톤 객체는 무상태로 설계해야한다 -> 특정 클라이언트에 의존적인 필드가 있으면 안된다

• @Configuration 에서 new 키워드로 객체를 매번 생성하고 있는 것처럼 보이지만 스프릥 컨테이너는 싱글톤 패턴을 적용하여 실제로 한 번만 객체를 생성하고 만다

[hokyung-lee]

스프링 핵심 원리 이해1 - 예제 만들기

• 프로젝트 생성

• 비즈니스 요구사항과 설계

• 회원 도메인 설계

• 회원 도메인 개발

• 회원 도메인 실행과 테스트

• 생각해볼 점 : MemberService가 Repository Interface와 구현체 모두에 의존하고 있음. OCP원칙을 지키고 있는것인가?

[dowon-ahn]

HTTP API

• HTTP는 리소스를 기반으로 설계해야한다.
• URI 계층 구조 활용
• 리소스와 행위를 분리 (리소스를 식별하는 것)
• 리스소는 명사 / 행위는 동사(

HTPP 메서드 종류

• GET : 리소스 조회
• POST : 요청 데이터 처리, 주로 등록에 사용
• PUT : 리소스를 대체, 해당 리소스가 없으면 생성
• PATCH : 리소스를 부분 변경
• DELETE : 리소스를 삭제

GET

• 리소스를 조회
• 서버에 전달하고 싶은 데이터는 쿼리를 통해서 전달
• 메세지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않음.

POST

• 요청 데이터 처리
• 메세지 바디를 통해 서버로 요청 데이터 전달
• 서버는 요청데이터를 처리
  • 메세지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다.
• 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용

요청 데이터를 처리한다는 것은?

• 이 리소스 URI에 POST 요청이 오면 데이터를 어떻게 처리할지 리소스 마다 정해야함 -> 서버 개발자 마음

PUT

• 리소스를 대체 / 없으면 생성 / 쉽게말하면 삭제 후 새로 쓰기
• 클라이언트가 리소스를 식별 / 클라이언트가 리소스 위치를 알고 URI 지정 (POST와의 차이점)

PATCH

• 리소스 부분 변경

DELETE

• 리소스 제거

HTTP 메서드의 속성

• 안전 / 멱등 / 캐시가능

[cxz5309]

스프링 핵심 원리 - 기본편

2. 객체 지향 원리 적용

• [x] 새로운 할인 정책 개발
• [x] 새로운 할인 정책 적용과 문제점
• [x] 관심사의 분리
• [ ] AppConfig 리팩터링
• [ ] 새로운 구조와 할인 정책 적용
• [ ] 전체 흐름 정리
• [ ] IoC, DI, 그리고 컨테이너
• [ ] 스프링으로 전환하기

새로은 할인 정책 적용과 문제점

추상(인터페이스) 뿐만 아니라 구체(구현) 클래스에도 의존하고 있다.
DIP 위반

따라서 기능을 확장해서 변경하면 소스코드도 함께 변경해야 한다. OCP 위반

-> 인터페이스에만 의존하도록 설계를 변경하자!
->> 누군가가 클라이언트에 구현 객체를 대신 생성하고 주입해주어야 한다.

관심사의 분리

• 배우는 본인의 역할인 배역을 수행하는 것에만 집중해야 한다.
• 디카프리오는 어떤 여자 주인공이 선택되더라도 똑같이 공연을 할 수 있어야 한다.
• 공연을 구성하고, 담당배우를 섭되하고, 역할에 맞는 배우를 지저ㅇ하는 책임을 담당하는 별도의 '공연 기획자'가 나올 시점이다.
• 공연 기획자를 만들고, 배우와 공연 기획자의 책임을 확실하게 분리하자

---

AppConfig의 등장

• 애플리케이션의 전체 동작 방식을 구성(config)하기 위해, '구현 객체를 생성' 하고, '연결' 하는 책임을 가지는 별도의 설정 클래스를 만들자.

• AppConfig는 애플리케이션의 실제 동작에 필요한 '구현 객체를 생성'한다.

• AppConfig는 생성한 객체 인스턴스의 참조(레퍼런스)를 '생성자를 통해서 주입(연결) 해준다

생성자 주입을 통해 '의존관계에 대한 고민은 외부'에 맡기고 '실행에만 집중'하면 된다.

• 클라이언트 입장에서 보면 의존관계를 마치 외부에서 주입해주는 것 같다고 해서 DI(Dependency Injection) 의존관계 주입 또는 의존성 주입이라고 한다.

정리

• AppConfig를 통해 관심사를 확실하게 분리
• AppConfig는 구체 클래스를 선택한다. 애플리케이션이 어떻게 동작해야 할지 전체 구성을 책임진다.

[char-yb]

uiurihappy 강의명: 스프링 핵심원리 기본편 회차: 중복등록과 충돌

컴포넌트 스캔에 의해 자동으로 스프링 빈이 등록되는데, 그 이름이 같은 경우 스프링은 오류를 발생시킨다. ConflictingBeanDefinitionException 예외 발생한다. 만약 수동 빈 등록과 자동 빈 등록에서 빈 이름이 충돌되면 수동 빈 등록이 우선권을 가진다.

수동 빈 등록시 남는 로그 Overriding bean definition for bean 'memoryMemberRepository' with a different definition: replacing

자동 보다는 수동이 우선권을 가지는 것이 좋다. 하지만 현실은 개발자가 의도적으로 설정해서 이런 결과가 만들어지기 보다는 여러 설정들이 꼬여서 이런 결과가 대부분이다. 최근 스프링 부트에서는 수동 빈 등록과 자동 빈 등록이 충돌나면 오류가 발생하도록 기본 값을 바꾸었다