선 조치 후 분석

@Configuration과 싱글톤(Singleton) @Configuration은 사실 싱글톤을 위해서 존재하는 것이다. 아래 코드를 보자. memberService를 호출하면, MemberServiceImpl을 호출하면서 memberRepository를 호출한다. @Bean memberService -> new MemoryMemberRepository() @Bean orderService -> new MemoryMemberRepository() 호출이 2번 일어난다. 그렇다면 이러면 싱글톤이 깨지는 거 아닐까?? @Configuration public class AppConfig { @Bean public MemberService memberService() { //return new MemberSe..

객체 지향 원리 적용 + 애자일이란? + Junit 자동생성 + OCP, DIP 위반 + 객체 주입 이번에 정리하는 내용은 기획자가 새로운 '할인 정책'을 추가하려고 하는 과정이다. 여러 과정을 거치면서, '스프링'의 원리를 파악해보자! 새로운 할인 정책을 확장해 보자. 더보기 악덕 기획자: 서비스 오픈 직전에 할인 정책을 지금처럼 고정 금액 할인이 아니라 좀 더 합리적인 주문 금액당 할인하는 정률% 할인으로 변경하고 싶어요. 예를 들어서 기존 정책은 VIP가 10000원을 주문하 든 20000원을 주문하 든 항상 1000원을 할인했는데, 이번에 새로 나온 정책은 10% 로지 정해두면 고객이 10000원 주문 시 1000원을 할인해주고, 20000원 주문 시에 2000원을 할인해주는 거예요! 순진 개발자..

프로젝트 생성 + 순수 Java로만 구성 + 비즈니스 요구사항 + 설계 + 클래스 다이어그램 + 객체 다이어그램 + 다형성(Overridng,Overloading) 스프링 부트 스터디 사이트에서 기본적으로만 사용되는 라이브러리 외 다른 건 사용하지 않고, '순수 Java'로 프로젝트를 먼저 만들어 보려고 한다. 이렇게 먼저 순수 Java로 진행해봐야 나중에 'Spring'을 사용하고 나서 어떤 차이가 있는지 제대로 공부해보자. 사용 IDE : 이클립스 언어 : Java11 https://start.spring.io/ build.gradle에서 'dependencies' 확인해보면 기본적인 2가지만 들어가 있는 것을 확인할 수 있다. dependencies { implementation 'org.sprin..

스프링 이야기에 왜 객체 지향 이야기가 나오는가? 스프링은 다음 기술로 '다형성 + OCP, DIP'를 가능하게 지원 1. DI(Dependency Injection) : 의존관계, 의존성 주입 2. DI 컨테이너 제공 클라이언트 코드의 변경 없이 기능 확장 쉽게 부품을 교체하듯이 개발 스프링이 없던 시절 옛날 어떤 개발자가 좋은 객체 지향 개발을 하려고 OCP, DIP 원칙을 지키면서 개발을 해보니, 너무 할 일이 많았다. 배보다 배꼽이 크다. 그래서 프레임워크로 만들어버렸다. 순수하게 자바로 OCP, DIP 원칙들을 지키면서 개발을 해보면, 결국 '스프링 프레임 워크'를 만들게 된다. (더 정확하게는 'DI 컨테이너') DI 개념은 말로 설명해도 이해가 잘 안 된다. 코드로 짜 봐야 필요성을 느낀다!..

좋은 객체란 뭘까? 많이 들어봤던 'SOLID'에 대해서 오늘은 정리를 해보려고 한다. 면접에서도 나오는 개념 중에 하나이므로 꼭 잘 이해해보자! SOLID 1. SRP - 단일 책임 원칙 (Single responsibility principle) 2. OCP - 개방-폐쇄 원칙 (Open/closed principle) 3. LSP - 리스코프 치환 원치식 (Liskov substitution principle) 4. ISP - 인터페이스 분리 원칙 (Interface segregation principle) 5. DIP - 의존관계 역전 원칙 (Dependency inversion principle) SRP - 단일 책임 원칙 (Single responsibility principle) 한 클래스는..

스프링 역사를 알려면 먼저 'EJB'를 알고 가야 한다. 'EJB(Enterprise Java Beans)'는 옛날 자바 진영의 표준 기술이었다고 한다. 당시에 '종합 선물 세트- (컨테이너, 트랜잭션 관리, 분산 기술, ORM이 포함)'였다고 할 정도였다. 하지만, 이론상으로는 너무 좋은데, 가격도 비싸고, 복잡하고 사용하기가 어렵다고 한다. 거기다가 느리기까지 했다고 한다. 컨테이너 한번 띄우는데 시간이 정말 치명적일 정도로 'EJB 지옥'이라고 했었다. 그래서 여기서 개발자들은 "오래된 방식의 순수한 자바로 돌아가자"라는 의미로 'POJO(Plain Old Java Object)'라는 단어를 사용했다고 한다. 이렇게 EJB 지옥에서 구해줄 2명의 개발자가 있었다고 한다. 1. 로드 존슨 2002년에..