Coding Story

컴포넌트 스캔 컴포넌트 스캔: 설정 정보가 없어도 자동으로 스프링 빈을 등록 @Component 어노테이션이 붙은 클래스를 스캔해서 스프링 빈으로 등록 (@Configuration안에도 Component어노테이션이 있기 때문에 컴포넌트 스캔의 대상이 됨) @Autowired: 의존관계 자동 주입 컴포넌트 스캔을 사용하려면 먼저 @ComponentScan 을 설정 정보에 붙여주면 된다. 컴포넌트 스캔을 쓰면 빈이 자동으로 등록되는데, 의존관계를 설정해줄 수 없으므로(이전 Appconfig 처럼 의존관계를 수동으로 등록 불가) 생성자에 @Autowired를 사용해 생성자의 매개변수 타입에 맞는 빈 객체를 스프링이 찾아 자동으로 주입해준다. 정리: 1. @ComponentScan은 @Component가 붙은 ..

스프링 없는 순수한 DI 컨테이너 AppConfig는 고객이 요청하는 만큼 객체를 생성해 반환 - 메모리 낭비 싱글톤: 클래스의 인스턴스가 딱 1개만 생성되는 디자인 패턴 private 생성자를 사용해 외부에서 임의로 new 키워드를 사용하지 못하도록 함 public class SingletonService { private static final SingletonService instance = new SingletonService(); // JVM이 맨처음 실행할 때 static 영역을 초기화 하면서 딱 한번 객체를 하나 생성 public static SingletonService getInstance(){ // 객체 인스턴스가 필요하면 이 static 메서드를 통해서만 조회하도록 허용 return ..

스프링 컨테이너 생성 스프링 컨테이너 생성 -> 스프링 빈 등록 -> 의존 관계 설정 1. 스프링 컨테이너 생성 ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class); // 구현체 ApplicationContext: 스프링 컨테이너, 인터페이스 스프링 컨테이너는 xml or 애노테이션 기반의 자바 설정 클래스(AppConfig)로 생성 가능 AppConfig.class로 구성 정보 지정 2. 스프링 빈 등록 설정 클래스에 @Bean 이 붙은 메서드 이름을 키로 해서 객체를 스프링 빈으로 등록 *빈이름 직접 부여 가능: @Bean(name=”memberService2”) *빈 이름은 항상 ..

memberRepository 인터페이스를 두 repository가 구현한다. memberService는 memberRepository 인터페이스만 의존하도록 한다. package com.hello.core.member; public class MemberServiceImpl implements MemberService{ //private final MemberRepository memberRepository = new MemoryMemberRepository(); // 실제 할당하는 부분이 구현체를 의존 // 인터페이스, 구현체 모두 의존 => dip 위반 private final MemberRepository memberRepository; // 추상화에만 의존하도록 한다. public MemberS..

스프링의 탄생 2000년대 초반 자바 진영에서는 EJB가 표준 기술이였다. 트랜잭션 관리, 분산 기술등의 장점 하지만 비싸고 어렵다. 복잡하고 느리다 → 스프링과 하이버네이트 탄생 표준 인터페이스 : JPA JPA 구현체들: 하이버네이트, eclipseLink… 스프링은 EJB의 문제점을 지적하면서 등장하였고, 이름은 전통적인 J2EE(EJB)라는 겨울을 넘어 새로운 시작이라는 뜻으로 짓게 됨 스프링이란? 스프링 데이터: CRUD를 편리하게 사용 가능 (스프링 데이터 JPA 기술 많이 사용) 스프링 세션: 세션 기능을 편리하게 사용 가능 스프링 시큐리티: 보안 관련 스프링 RestDocs: API 문서와 테스트를 엮어 문서화를 편하게 해주는 것 스프링 배치: 배치처리(실시간으로 대량 데이터를 업데이트)에..

다형성과 설계 객체 지향 프로그래밍: 객체들들이 메세지를 주고받고 데이터를 처리 다형성은 역할과 구현으로 세상을 구분 하는 것 - 클라이언트는 구현 대상 자체가 변경해도 영향을 받지 않고, 대상의 역할(인터페이스)만 알면 된다.- 유연, 변경 용이 역할 = 인터페이스구현 = 인터페이스를 구현한 클래스  자바 언어의 다형성 ⇒ 오버라이딩  OCP(Open - Closed Principle)새로운 기능이 추가 되었을 때, 기존 코드는 확장할 수 있다.기존의 코드는 수정되지 않아야 한다. 운전자는 자동차 인터페이스만 참조해 자동차 역할에만 의존한다.새로운 차량을 추가해도 운전자의 코드는 바뀌지 않는다.

문제점Animal 클래스를 생성할 필요가 없다.Animal 클래스를 상속받는 곳에서 sound() 메서드를 오버라이딩 하지 않을 가능성이 있다.⇒ 추상 클래스 도입  추상 클래스추상적인 개념을 제공하는 클래스로, 인스턴스가 존재하지 않는다.기존 클래스와 완전히 같지만, new AbstractAnimal()와 같이 직접 인스턴스를 생성하지는 못한다. abstract class AbstractAnimal {...}추상 메서드 추상적인 개념을 제공하는 메서드로 실체가 존재하지 않는다.자식 클래스가 반드시 오버라이딩 해야 한다.public abstract void sound(); -추상 메서드가 하나라도 있는 클래스는 추상 클래스로 선언해야 한다.(그렇지 않으면 컴파일 오류 발생)추상 메서드는 메시지 바디가 없..

다형성한 객체가 여러 타입의 객체로 취급될 수 있는 능력  [다형성의 핵심 이론]다형적 참조: 하나의 변수 타입으로 다양한 자식 인스턴스를 참조할 수 있는 기능메서드 오버라이딩: 기존 기능을 하위 타입에서 새로운 기능으로 재정의  다형적 참조 부모 타입의 변수가 자식 인스턴스 참조 가능 Parent poly = new Child();  자식 타입인 Child를 생성했기 때문에 메모리 상에 Child, Parent 모두 생성 💡 부모는 자식을 담을 수 있다.   상속 관계는 부모 방향으로 찾아 올라갈 수 있지만 반대는 불가능하다.poly 는 Parent 타입이므로 childMethod() 를 찾을 수 없어 컴파일 오류 → 캐스팅이 필요   다형성과 캐스팅 다운캐스팅Parent poly = new Chil..

상속 기존 클래스의 필드와 메서드를 새로운 클래스에서 재사용하게 해 준다.이름 그대로 기존 클래스의 속성과 기능을 그대로 물려받는 것이다. 자바는 다중 상속을 지원하지 않는다.같은 이름의 메서드를 가진 여러 클래스를 상속 받는다면, 어떤 메서드를 선택해야 할지 모르는 문제가 있기 때문이다.   상속과 메모리 구조  new 키워드로 자식이 생성될 때 부모 인스턴스까지 포함해 인스턴스를 생성한다.(참조값은 하나지만 그 안에 두가지 클래스 정보가 공존) 참조값.메서드()를 하면호출하는 변수의 타입(클래스)을 기준으로 메서드를 찾는다. 자식 클래스의 참조값.메서드()시 자식 클래스에 해당 메서드가 없으면 부모 클래스에서 찾아 호출한다.계속 올라가 찾아도 없으면 컴파일 오류   상속과 메서드 오버라이딩 오버라이딩..

Final  변수에 final 키워드가 붙으면 값을 변경할 수 없다.final 을 지역 변수에 선언 시 최초 한번만 할당할 수 있다.매개변수에 final 선언 시 메서드 내부에서 매개변수에 값을 변경할 수 없다. //final 필드 - 생성자 초기화 public class ConstructInit { final int value; public ConstructInit(int value) { this.value = value;} } final을 필드에서 사용할 경우 필드는 생성자를 통해서 한번만 초기화 가능 //final 필드 - 필드 초기화 public class FieldInit { static final int CONST_VALUE = 10; final in..