갑자기 왜 객체지향의 4대 원칙을 정리하냐 함은... 매번 기억이 잘 안남기에 다시 공부하고 이에 대해 정리를 해보기 위함이다.참고한 책은 '스프링 입문을 위한 자바 객체 지향의 원리와 이해' 이다.객체는 단순하게 이야기하면 이 세상에 존재하는 유일무이한 사물 이라고
한 클래스는 하나의 책임만 가져야 한다.즉, 하나의 클래스에 변경이 있는데 그 사이드 이펙트가 적으면 단일 책임 원칙을 잘 따른 것이라고 할 수 있다.소프트웨어 요소는 확장에는 열려있어야 하나, 변경에는 닫혀 있어야 한다.즉, 기능을 변경하거나 확장할 수 있으면서 그
이전 글에서 객체 지향 설계 원칙의 함정이라는 내용을 썼었다.그 글의 마지막에 스프링에서는 DI를 통해서 다형성, 그리고 OCP, DIP를 가능하게 하였다고 했는데 우리는 그에 대한 코드를 보며 확인해보자. 이해를 위해 간단한 코드를 작성하였다.빠른 예시 작성을 위해
해당 내용은 '스프링 입문을 위한 자바 객체 지향의 원리와 이해'와 인프런 김영한님의 '스프링 핵심 원리 - 기본편' 강의를 참고하였습니다. 자 전의 자바 어플리케이션 코드를 이제 우리는 Spring 으로 변경하려고 한다. 우선 ApplicationConfig 파일
스프링은 애초에 기업용 온라인 서비스를 지원하기 위해서 탄생했다.그리고 이러한 온라인 서비스는 여러명의 고객이 한번에 접속해서 사용하는 법이다. 그런데 이러한 온라인 서비스에서 고객의 요청이 올때마다 매번 인스턴스를 생성해서 사용한다면...어떨 것 같은가? 소규모의 서
해당 내용은 '스프링 입문을 위한 자바 객체 지향의 원리와 이해'와 인프런 김영한님의 '스프링 핵심 원리 - 기본편' 강의를 참고하였습니다.이전에 우리의 Config 파일을 보자.ApplicationConfig.java위의 파일에서 보면 Bean에 등록될 때 다음과 같
@ComponentScan이란, @Component라는 어노테이션이 붙은 클래스들을 스캔해서 자동으로 스프링 빈으로 등록해주는 어노테이션이다. 참고 : @Component 가 이미 붙어있는 다른 어노테이션들이 있는데, 이를 유의해서 사용하도록 하자. @Configur
지금이야 간단한 프로젝트에서 구성을 하니 당연히 Component 를 스캔하는데 얼마 걸리지 않겠지만, 실무에서는 다르다. 그렇기에 우리는 우리가 필요한 부분만 스캔하도록 하는 basePackages 또는 basePackageClasses 옵션을 이용해서 좀 더 빠르게
Bean이 만약 같은 이름으로 등록되는 경우가 있다면 어떻게 되는 걸까?여러 사람들이 같이 이용하는 코드에서 동일한 이름으로 Component를 등록한다면 어떻게 될까?그러면 ConflictingBeanDefinitionException 이 터진다. 펑-예를 들어보자.
해당 내용은 '스프링 입문을 위한 자바 객체 지향의 원리와 이해'와 인프런 김영한님의 '스프링 핵심 원리 - 기본편' 강의를 참고하였습니다.이름 그대로 생성자를 통해서 의존 관계를 주입받는 방법특징생성자 호출 시점에 딱 1번만 호출되는 것이 보장된다.불변, 필수 의존관
해당 내용은 '스프링 입문을 위한 자바 객체 지향의 원리와 이해'와 인프런 김영한님의 '스프링 핵심 원리 - 기본편' 강의를 참고하였습니다.자 조금만 생각해보자.우리는 여태 많은 방법의 의존성 주입방법을 배웠다.근데 우리가 주로 사용하는건 항상 생성자 주입이다.왜 생성
해당 내용은 '스프링 입문을 위한 자바 객체 지향의 원리와 이해'와 인프런 김영한님의 '스프링 핵심 원리 - 기본편' 강의를 참고하였습니다.조회되는 빈이 2개 이상인 경우에는 어떻게 원하는 빈을 지정할까?앞서 만들었던 클래스 구조에서 확인해보자. 우리는 FuelTank
해당 내용은 '스프링 입문을 위한 자바 객체 지향의 원리와 이해'와 인프런 김영한님의 '스프링 핵심 원리 - 기본편' 강의를 참고하였습니다.의도적으로 특정 타입의 스프링 전부 필요할 때가 있다. 요청 또는 로직에 따라서 필요한 빈을 바꿔줘야 할 때가 있기 때문이다.자
해당 내용은 '스프링 입문을 위한 자바 객체 지향의 원리와 이해'와 인프런 김영한님의 '스프링 핵심 원리 - 기본편' 강의를 참고하였습니다.예를 들어 DB 커넥션 풀이나, 네트워크 소켓처럼 애플리케이션 시작 시점에 필요한 연결을 미리 해두고, 애플리케이션 종료 시점에
스프링 빈은 스프링 컨테이너의 시작과 함께 생성되고, 스프링 컨테이너가 종료될 때까지 유지된다.이와 같이 스프링 빈이 존재할 수 있는 범위를 의미하는 것을 우리는 스코프 라고 한다.스프링은 다음과 같은 스코프를 지원한다.싱글톤 : 기본 스코프, 스프링 컨테이너의 시작과
해당 내용은 '스프링 입문을 위한 자바 객체 지향의 원리와 이해'와 인프런 김영한님의 '스프링 핵심 원리 - 기본편' 강의를 참고하였습니다.이전에 배웠듯, 스프링 컨테이너에 프로토타입 빈을 요청하면 항상 새로 생성해서 반환받는다.그러나 이러한 프로토타입빈을 싱글톤 빈과
해당 내용은 '스프링 입문을 위한 자바 객체 지향의 원리와 이해'와 인프런 김영한님의 '스프링 핵심 원리 - 기본편' 강의를 참고하였습니다.이전에는 싱글톤, 프로토타입에 대해 알아보았으니 이제는 웹 스코프에 대해서도 알아보자.웹 스코프의 특징은 다음과 같다.웹 환경에서
흔하게 어노테이션을 쓰다보면, 편하게 All-in-One의 느낌으로 @Data 를 사용하는 경우가 많다.그러나 이는 지양해야하는 행동이다.흔히 화장품에서 보듯 올인원 제품은 좋지않ㄱ....가 아니라...무분별히 @Data를 사용하면, 안에 들어가있는 @ToString,