search

spring-god-study / spring-basic

김영한님 스프링 기본 강의를 듣고 서로 인증하고 힘을 내며 잇쌰잇쌰하는 프로젝트
0 stars 3 forks source link

2021.07.17 / 2021.07.18 (주말) 인증 #11

Open kyupid opened 3 years ago

kyupid commented 3 years ago

주말 (토,일) 중에 최소 1개

cxz5309 commented 3 years ago

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

Eclipse -> IntelliJ 프로젝트 환경 변경 오류 해결 문제로 어제 못했습니다. IntelliJ로 프로젝트 처음부터 다시 시작하여 진행 https://github.com/cxz5309/Spring_Basic_Study

kimminju commented 3 years ago

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

  1. SOLID 1) 클린코드로 유명한 로버트 마틴이 좋은 객체 지향 설계의 5가지 원칙을 정리 2) SRP: 단일책임원칙(single responsibility principle)
    • 한 클래스는 하나의 책임만 가져야 한다.
    • 중요한 기준은 변경이다. 변경이 있을 때 파급효과가 적으면 단일책임원칙을 잘 따른 것 ex) UI변경, 객체의 생성과 사용을 분리 3) OCP: 개방-폐쇄원칙(Open/closed principle)
    • 가장 중요한 원칙
    • 소프트웨어 요소는 확장에는 열려져 있고 변경에는 닫혀 있어야 함
    • 다형성 활용
    • 인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능 구현
    • 문제점 : 구현 객체를 변경하려면 클라이언트 코드를 변경해야 함.
    • 해결방법: 객체를 생성하고 연관관계를 맺어주는 별도의 조립, 설정자가 필요(스프링컨테이너) 4) LSP: 리스코프 치환 원칙(Liskov substitution principle)
    • 프로그램의 객체는 프로그램의 정확성을 깨뜨리지않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 함
    • 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 함, 다형성을 지원하기 위한 우너칙, 인터페이스를 구현한 구현체는 믿고 사용하려면 이 원칙 필요 (인터페이스(자동차), 구현체가 구현(엑셀을 밟으면 앞으로 가야함) -> 엑셀을 뒤로 가게 구현하면 LSP위반임) 5) ISP: 인터페이스 분리 원칙(Interface segregation principle)
    • 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다
    • 인터페이스 명확, 대체 가능성 높음
    • 자동차 인터페이스 -> 운전 인터페이스, 정비 인터페이스로 분리
    • 사용자 클라이언트 -> 운전자 클라이언트, 정비사 클라이언트로 분리
    • 분리하면 정비 인터페이스 자체가 변해도 운전자 클라이언트에 영향x 6) DIP: 의존관계 역전 원칙(Dependency inversion principle)
    • 프로그래머는 "추상화 의존, 구체화 의존x"
    • 구현 클래스 의존x 인터페이스에 의존
    • 역할(role)에 의존하게 해야 함.
    • 클라이언트가 인터페이스에 의존해야 유연하게 구현체 변경가능
    • 의존 : 내가 저 코드를 안다 ex) //인터페이스, 구현클래스 둘다 의존 public class MemerService{ //왼쪽 인터페이스 오른쪽 구현클래스 private MemberRepository memberRepository = new MemotyMemberRepository(); }
  2. 스프링 1) 다형성 + OCP, DIP를 가능하게 지원
    • DI(Dependency Injetion) : 의존관계, 의존성 주입
    • DI 컨테이너 제공 (자바 객체들을 컨테이너에 넣어놓고 의존관계를 서로 연결해주고 주입해주는 기능 제공) 2) 위의 것들 활용하면 클라이언트 코드의 변경없이 기능 확장 가능
  3. 정리 1) 객체지향의 핵심은 다형성 2) 다형성 만으로는 쉽게 개발할 수 없다 3) 다형성 만으로는 구현객체를 변경할 때 클라이언트 코드도 함께 변경 됨 4) 다형성 만으로는 OCP, DIP를 지킬 수 없음 5) 모든 설계에 역할과 구현 분리 6) 인터페이스를 만들어두고 구현클래스만 유연하게 변경할 수 있도록 만드는 것이 좋은 객체 지향설계다 7) 이상적으로는 모든 설계에 인터페이를 부여하자. 8) 실무고민
    • 인터페이스를 도입하면 추상화라는 비용 발생(구현체 확인이 한 번에 안되서 코드를 여러개 확인해야 한다.)
    • 기능을 확장할 가능성이 없다면 구체 클래스를 직접사용, 향후 꼭 필요할때 리펙터링해서 인터페이스 도입
dnjsrud3407 commented 3 years ago

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

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

요약

narafu commented 3 years ago

강의명 : 스프링 입문

섹션 1 (월)

섹션 2 (화)

섹션 3 (수)

섹션 4 (목)

섹션 5 (금)

이번주까지 입문을 다 들을 계획이었으나 여러 약속이 생겨서 다 마치지 못했습니다.

char-yb commented 3 years ago

uiurihappy 강의명: 스프링 핵심원리 기본 회차: 탐색위치와 기본 스캔 대상~ 필터

탐색위치와 기본 스캔 대상 basePackages : 탐색할 패키지의 시작 위치를 지정한다. 이 패키지를 포함해서 하위 패키지를 모두 탐색한다. basePackages = {"hello.core", "hello.service"} 이렇게 여러 시작 위치를 지정할 수도있다. basePackageClasses : 지정한 클래스의 패키지를 탐색 시작 위치로 지정한다. 만약 지정하지 않으면 @ComponentScan 이 붙은 설정 정보 클래스의 패키지가 시작 위치가 된다.

권장하는 방법은 설정 정보 클래스의 위치를 프로젝트 최상단에 두는 것이다.

컴포넌트 스캔의 용도 뿐만 아니라 다음 애노테이션이 있으면 스프링은 부가 기능을 수행한다. @Controller : 스프링 MVC 컨트롤러로 인식 @Repository : 스프링 데이터 접근 계층으로 인식하고, 데이터 계층의 예외를 스프링 예외로 변환해준다. @Configuration : 앞서 보았듯이 스프링 설정 정보로 인식하고, 스프링 빈이 싱글톤을 유지하도록 추가 처리를 한다. @Service : 사실 @Service 는 특별한 처리를 하지 않는다. 대신 개발자들이 핵심 비즈니스 로직이 여기에 있겠구나 라고 비즈니스 계층을 인식하는데 도움이 된다.

필터 includeFilters : 컴포넌트 스캔 대상을 추가로 지정한다. excludeFilters : 컴포넌트 스캔에서 제외할 대상을 지정한다