EEALL@ONCE

TRUNCATE TABLE 테이블명; 해당 쿼리문은 테이블은 그대로 두고 그 안에 데이터만 삭제하는 경우에 사용된다.

중복을 없애고, 역할에 따른 구현이 확실해야한다. 리펙터링 할 때 지켜야하는 점: 1. 구성 정보에서 역할과 구현을 명확하게 분리 2. 중복 제거 [리팩터링 전] public class AppConfig { public MemberService memberService() { return new MemberServiceImpl(new MemoryMemberRepository()); } public OrderService orderService(){ return new OrderServiceImpl(new MemoryMemberRepository(),new FixDiscountPolicy()); } } [리팩터링 후] public class AppConfig { /* 각자 부분을 정확히 나눔 */ publ..

1. 이전 글 문제점 클라이언트 코드인 OrderServiceImpl이 인터페이스들 뿐만이 아니라, 구체 클래스 ( FixDiscountPolicy,RateDiscountPolicy)에도 의존했다. 쉽게 말하자면, 해당 코드에 구체 클래스 코드가 들어간다는 것!! 2. 클라이언트가 인터페이스에만 의존하도록 만들자. public class OrderServiceImpl implements OrderService{ 안에 private DiscountPolicy discountPolicy; 인터페이스만 선언해준다. 근데 그럼 구현체가 없는데 어떻게 코드를 실행할 수 있을까? 3.역할 분리 후 주입 인터페이스는 인물이고 구현체는 배우라고 가정하자. 그리고 여기서 클라이언트가 연극 작가라고 한다면, 연극 작가는 ..

1. FROM [주 마다 얼마나 자주 범죄가 발생하는지 알아보기 ] SELECT daily_stats.week , AVG(daily_stats.incidents_daily) FROM ( SELECT week , date , COUNT(incident_id) AS incidents_daily FROM crimes GROUP BY week, date ) daily_stats GROUP BY daily_stats.week 가상의 새로운 테이블을 만들고, 해당 테이블 이름을 daily_stats라고 한다. 서브쿼리로 만들어진 가상의 daily_stats table ( SELECT week , date , COUNT(incident_id) AS incidents_daily FROM crimes GROUP BY w..

1. 애자일 소프트웨어 개발 선언 (계획을 따르기보다 변화에 대응 순응하기를!) 개발을 하다보면, 애자일 방식을 사용할 수 밖에 없다. 사실 기획자도 자신이 뭘 하고 싶은지 정확하게 모를 때가 많다! 그때마다, 개발자는 만들어서 보여주고 기획자에게 역으로 방법을 재시한다던가, 아님 기획자가 중간에 자신이 깨닫지 못한 부분을 추가하고 싶을 때, 변화게 순응해서 또 그렇게 만들어줘야한다. 왜냐면... 기획이란 그런거고... 개발자란 그걸 실행시키는 역할이니까... 어쩔 수 없다. 2. 다시 바뀐 할인 정책 이야기로 돌아가자 고정 금액 할인에서 고정 퍼센트 할인으로 바꾼다. 🥑 RateDiscountPolicy(%할인율) package hello.core.discount; import hello.core.me..

1. 상황 할인 정책 마음을 안 정한 사장과 머리가 아픈 개발자 현 상황은 vip에게 고정 할인 or 회원 등급에 따라 할인 등을 고민중이다. 2. 주문 도메인 협력,역할,책임 클라이언트가 주문을 하면, 서비스는 회원 조회를 하고 그에 따른 할인을 적용하고 할인 결과를 포함한 주문 결과를 클라이언트에게 돌려준다. 3. 고정 할인 코드 설계 member 패키지는 회원 정보 로직이 / discount 페키지에는 할인 로직이 / order 페키지에는 주문 로직이 담겨있다. 순서는 각 패키지마다 DTO/Repository /Service/Main순서로 코드를 보여주겠다. 🥑 member 패키지 🔻 member 객체 (DTO) package hello.core.member; public class Member {..

• SRP: 단일 책임 원칙(single responsibility principle) 단일 책임 원칙은 한 클래스는 하나의 책임을 가져야 한다는 것다. 조금 모호한 개념이다. 큰 책임 작은 책임, 하나의 책임이라고 해도 그 규모가 다르다. 그래서 기준은 "변경"이다. 만약 변경이 필요한 시점에서 너무 많은 변경이 필요하다면, 단일 책임 원칙이 잘 지켜지지 않은 것이다. • OCP: 개방-폐쇄 원칙 (Open/closed principle) 소프트웨어 요소는 확장에는 열려있으나 변경에는 닫혀 있어야 한다는 원칙 사실 인터페이스만 생각해도 뭔가 그럴싸한 이야기이지만, 사실 구현을 바꾸면, 클라이언트쪽에서도 구현 클래스를 직접 선택해야해서, 코드 수정이 불가피하다. 예를 들어 이 경우도 클라이언트가 기존 A..

1. 스프링이란? -자바(객체 지향) 언어 기반의 프레임워크 -스프링은 좋은 객체 지향 애플리케이션을 개발할 수 있게 도와주는 프레임워크 그렇다면... 2. 좋은 객체 지향 언어란? 객체 지향 특징 1. 추상황 2. 캡슐화 3. 상속 4. 다형성 그 중에서도 다형성이 중요한데.. 다형성이란? 3. 다형성 역할과 구현을 분리하는 것 클라이언트는 대상의 역할만 알면 된다. 클라이언트는 구현 대상의 내부 구조가 변경되어도 영향을 받지 않는다. 클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않는다. 역할 = 인터페이스 / 구현 = 인터페이스를 구현한 클래스,구현 객체 따라서, 🔻객체 설계시 인터페이스를 먼저 부여하고, 그 역할을 수행하는 구현 객체 만들기 역할이 구현보다 중요하다!! 자바 언어의 다형성에서..