2021.07.15 (목) 인증

[kyupid]

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

[sablemarten]

객체 지향 설계와 스프링

• 책 홍보 느낌이 강했음, 물론 다 읽어봐야겠지만 ㅠㅠ

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

• 프로젝트 생성
• 비즈니스 요구사항과 설계
• 회원 도메인 설계
• 회원 도메인 개발
• 열심히 따라쳤습니다. Assertions.assertThat 요거 해결책 찾는 중!

[arangeblue]

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

수강 회차 : 섹션 7 마무리 / 조회 빈이 2개 이상일 때 ~ 자동, 수동의 올바른 실무 운영 기준

요약

• @Autowired를 하면 기본적으로 타입으로 조회한다. cf) FixDiscountPolicy, RateDiscountPolicy
• 빈을 조회할 때 같은 이름이 2개 이상일 때, 충돌이 발생한다.
• 이 때 몇 가지 해결방법이 있다.
• 1. @Autowired 필드 명 매칭
• 2. @Qualifier 사용 / 이 방법은 추가 구분자를 부여해주는 방법, 빈 이름을 변경하는 것은 아니다.
• 3. @Primary 말 그대로 우선권을 지정해주는 방법
• 만약 @Qualifier, @Primary를 같이 사용한다면 더 상세하게 좁은 범위를 제공해주는 @Qualifier가 우선권을 가진다.
• @Qualifier("") 이렇게 만들면 컴파일 시 타입 체크가 되지 않는다. 이 때 custom annotation을 만들어 문제를 해결할 수 있다.
• 조회한 빈이 모두 필요할 때, 조회한 빈을 Map이나 List에 담아서 활용할 수 있다.
• 자동 빈 등록, 수동 빈 등록의 실무적 기준은 명확하게 구분되어 있지 않지만 기술 지원 객체에는 수동 등록을, 다형성을 적극 활용하는 비즈니스 로직에는 수동 등록을 고민해보자.

[dowon-ahn]

HTTP

모든것을 http에 담아 전송이 가능하다.

http 2,3 은 1.1을 성능개선에 가까우므로 1.1의 스펙을 이해하는것이 가장 중요

http 1.1 / 2 는 TCP위에서 동작 http 3는 UDP위에서 동작

클라이언트 서버 구조

• 각각 독립적인 구조를 가짐
• 클라이언트가 요청을 보내면 서버는 응답하는 구조(가장 간단히 설명하자면)

비연결성

• HTTP는 기본이 연결을 유지하지 않는 모델
• 일반적으로 초 단위 이하의 빠른 속도로 응답
• 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 적음 e.g. 웹 브라우저에서 페이지 로딩후 연속해서 버튼을 누르는 경우는 거의 없음
• 서버 자원을 매우 효율적으로 사용할 수 있음

한계와 극복

• TCP / IP 연결을 새로 맺어야함 - 3 way handshake 시간 추가
• 웹 브라우저로 사이트를 요청하면 HTML을 포함한 자바스크립트, css, 이미지 등 수많은 자원이 다운로드
• 지금은 지속연결 (Persistent Connection)로 문제 해결
• HTTP/2, HTTP/3에서 많은 최적화

HTTP 메세지 

• HTTP 메세지에 모든것을 전송
• HTTP 역사 HTTP/1.1을 기준으로 학습
• 클라이언트 서버 구조
• 무상태 프로토콜(stateless)
• HTTP 메세지
• 단순함, 확장 가능

[kimminju]

2021.07.16 강의명 : 스프링 핵심 원리 기본편 섹션 1

1. 객체지향특징 : 추상화, 캡슐화, 상속, 다형성
2. 객체지향프로그래밍 1) 컴퓨터 프로그램을 명령어의 목록으로 보는 시각에서 벗어나 여러개의 독립된 단위, 즉 객체들의 모임으로 파악하고자 하는 것이다. 2) 객체는 메시지를 주고받고 데이터를 처리할 수 있다. 3) 프로그램을 유연하고 변경이 용이하게 만듬 4) 대규모 소프트웨어 개발에 많이 사용
3. 다형성 1) 다형성의 본질
   • 인터페이스를 구현한 객체 인스턴스를 실행 시점에 유연하게 변경가능
   • 다형성의 본질을 이해하려면 협력이라는 객체 사이의 관계에서 시작해야함
   • 클라이언트를 변경하지 않고, 서버의 구현기능을 유연하게 변경할 수 있다. 2) 정리
   • 실세계의 역할과 구현이라는 편리한 컨셉을 다형성을 통해 객체 세상으로 가져올 수있음
   • 유연하고 변경이 용이
   • 확장 가능한 설계
   • 클라이언트에 영향을 주지 않는 변경 가능
   • 인터페이스를 안정적으로 잘 설계하는 것이 중요 3) 한계
   • 역할(인터페이스) 자체가 변하면, 클라이언트 서버 모두에 큰 변경 발생
4. 스프링과 객체지향 1) 다형성을 극대화해서 이용할 수 있게 도와줌 2) 제어의 역전(IoC), 의존관계 주임(DI)은 다형성을 활용해서 역할과 구현을 편리하게 다룰 수 있도록 지원 3) 구현을 편리하게 변경 가능

[cxz5309]

객체 지향 설계와 스프링

스프링은 다음 기술로 다형성 + OCP, DIP를 가능하게 지원

• DI: 의존관계, 의존성 주입
• DI 컨테이너 제공 클라이언트 코드 변경 없이 기능 확장

정리

• 모든 설계에 역할과 구현을 분리하자.
• 이상적으로는 모든 설계에 인터페이스를 부여하자.
  • 하지만 실무에서는 인터페이스를 도입하면 추상화라는 비용이 발생
  • 기능 확장 가능성이 없다면, 클래스를 직업 사용하고, 향후 필요할 때 리팩토링해서 인터페이스를 도입하는 방법이 있다.

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

• [x] 프로젝트 생성
• [x] 비즈니스 요구사항과 설계
• [x] 회원 도메인 설계
• [x] 회원 도메인 개발
• [x] 회원 도메인 실행과 테스트
• [x] 주문과 할인 도메인 설계
• [x] 주문과 할인 도메인 개발
• [x] 주문과 할인 도메인 실행과 테스트

https://github.com/cxz5309/Spring_Basic_Study

[char-yb]

uiurihappy 강의명: 스프링 핵심원리 기본편 강의 회차: 싱글톤 방식의 주의점~@Configuration과 바이트코드 조작의 마법 싱글톤 방식의 주의점

• 싱글톤 패턴이든, 스프링 같은 싱글톤 컨테이너를 사용하든, 객체 인스턴스를 하나만 생성해서 공유하는 싱글톤 방식은 여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 상태를 유지(stateful)하게 설계하면 안됨.(무상태)

@Configuration과 싱글톤

• 특정 클라이언트에 의존적인 필드가 있으면 안된다.
• 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다!
• 가급적 읽기만 가능해야 한다.
• 필드 대신에 자바에서 공유되지 않는, 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다.

@Configuration과 바이트코드 조작의 마법

• 스프링 컨테이너는 싱글톤 레지스트리다. 따라서 스프링 빈이 싱글톤이 되도록 보장해주어야 한다.
• 스프링은 클래스의 바이트코드를 조작하는 라이브러리를 사용한다
• @Bean만 사용해도 스프링 빈으로 등록되지만, 싱글톤을 보장하지 않는다.
• memberRepository() 처럼 의존관계 주입이 필요해서 메서드를 직접 호출할 때 싱글톤을 보장하지 않는다.
• 크게 고민할 것이 없이 스프링 설정 정보는 항상 @Configuration 을 사용!

[dnjsrud3407]

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

수강 회차 <스프링 핵심 원리 이해2 - 객체 지향 원리 적용>

• AppConfig 리팩터링
• 새로운 구조와 할인 정책 적용
• 전체 흐름 정리

요약

• AppConfig를 생성하면서 프로그램을 사용 영역과 구성 영역으로 나누게 되었다
• 구현체를 바꿀 때 사용 영역인 클라이언트 코드를 전혀 건들이잊 않고 바꿀 수 있다