컴퓨터 탐험가 찰리

1. IoC(Inversion of Control) : 제어의 역전 이전 글에서 사용영역과 구성 영역을 구분함으로써 객체 지향 설계 원칙을 지킬 수 있었다. 구성 정보를 설정하는 AppConfig 클래스를 만들어서 객체를 생성하고, 할당하였다. 이전글 : 6. 사용영역과 구성영역 나누기로 SRP, OCP, DIP 원칙 실현하기 IoC는 용어의 이름에서 알 수 있듯, 구성 정보를 내가(실행 코드가 있는 객체가) 직접 설정하는 것이 아니라, 외부(라이브러리, 프레임워크 등)에서 이런 과정을 대신해주는 것을 의미한다. -> AppConfig.class 파일에서 구성 정보를 설정해주는 것도 IoC라고 할 수 있다. 2. DI(Dependency Injection) DI는 직역하면 '의존 관계 주입' 이지만, 좀..

1. 변경 코드 적용 : RateCaringPolicy 동물원의 정책이 바뀌어서, FixedCaringPolicy에서 RateCaringPolicy로 변경됬다. 다행히도 다형성을 지켜가면서 인터페이스로 역할을 만들어놨기 때문에, 기존 인터페이스를 상속받는 새로운 클래스를 만들기가 수월하다. RateCaringPolicy CaringPolicy 역할(interface)을 그대로 상속받기 때문에 작성해놓았던 totalExpense 메서드를 그대로 활용할 수 있다. 2. SRP, OCP, DIP 위반 그런데, 바뀐 RateCaringPolicy를 적용하기 위해서 클라이언트와 소통하는 Service 코드를 살펴보면 OCP, DIP 그리고 SRP가 위반되어 있는 것을 알 수 있다. 아래 코드를 보면서 뭐가 잘못된..

1. 예제 확장 위 그림과 같이 예제를 확장해보자. Plan(Creature, CaringPrice, Policy) 관리 계획에서는 Plan이라는 객체가 있고, Plan은 생물(creature)의 종류, 생물 종류에 따른 Caring Price, 관리 정책 Policy에 의해 제어된다. Service, 로직을 구현하는 위치 클라이언트로부터 받은 파라미터 값을 검증(validation)하거나, 계산하는 등 input값을 바탕으로 적절한 output을 만들어 내는 곳이다. Creature, 관리 대상인 생물들 생물들은 각기 무게(weight)가 있고, 무게에 비례하게 관리 비용(expense)이 든다고 가정한다. 또한 동물이든 식물이든 멸종위기 종의 기준인 Grade가 있어서, 일반 종은 Normal, 멸종..

1. 예시 프로젝트 구조 김영한님의 강의를 그대로 따라하는 것보단, 조금 내용을 바꿔가며 학습해야 생각을 하면서 학습할 수 있을 것 같다. 강의에서는 회원들의 정보를 다루는 도메인을 예시로 든다. 이와 유사하게 동물원을 만든다고 생각하고, 동물원에 포함된 생물들(Creature)을 관리하는 도메인을 만들어보자. 구조는 아래 그림과 같이 강의 내용과 동일하다. Service와 Repository는 기본적으로 Interface 형태로 만든다. 여기서 핵심은, 객체를 interface로 만들어서 다형성을 활용하여 코드의 변경이 용이하게 한다는 점이다. CreatureRepository를 상속받는 구현체가 CreatureRepositoryAnimals가 되든, CreatureRepositoryPlants가 되든..

1. 객체 지향 프로그래밍이란 프로그램은 행사나 연주회 등에서 "XXX 프로그램" 이라고 말하는 것처럼, 작성해놓은 코드가 한 줄씩 차례대로 실행되는 순차적인(절차적인) 방식으로 동작한다. 절차지향 프로그래밍이란, 이런 프로그램의 기본적인 특성에 맞춰서 하나의 파일을 순차적으로 실행되도록 구성하는 것을 말한다. 그러나 객체 지향 프로그래밍은 단순히 한개의 파일에서 순서대로 작성해놓은 코드가 실행되도록 하는 것이 아니라, 여러 개의 독립된 단위, 즉 "객체" 들의 모임으로 프로그램을 바라보는 시각을 말한다. 자바에서는 클래스나 인터페이스 파일들이 객체라고 할 수 있겠다. 이렇게 생성된 객체들은 서로 데이터를 주고받으며 동작한다. 객체들끼리 데이터를 주고 받으며 작동하는 프로그램을 만드는 이유는, 프로그램을..

상황 QueryDsl을 이용해서 Entity 에서 전체 필드를 호출하는 것이 아니라, 특정 필드들만 호출하거나, 연관된 다른 Entity의 필드를 동시에 호출하고 싶다면 아래와 같이 Projections.constructor를 사용한다. Repository쪽 코드 1 2 3 4 5 6 7 8 9 10 jpaQueryFactory .select(Projections.constructor(XxxDto.class , Xxx1Entity.id.as("id") , Xxx1Entity.name.as("siteName") , Xxx2Entity.visitor ) ) .from(...) ... Colored by Color Scripter cs XxxDto쪽 코드 1 2 3 4 5 6 7 8 9 @Data @Build..

필요성 정확한 프로그램을 만들기 위해서 생각할 수 있는 최대한의 경우의 수를 테스트 해보는 것이 당연히 유리하다. 그리고 이러한 테스트를 하나의 기능별로 구분해서 진행해본다면, 개발자가 명확한 논리를 갖게 되고 테스트를 하는 것이 쉬워진다. 또한 새로운 기능이 추가되거나 수정사항이 생기더라도 어떤 테스트에서 문제가 생겼는지 정확히 알 수 있고 유지보수하기가 편함을 상식적으로 알 수 있다. 위 방법대로 수행하는 것이 일반적이다. 그러나 TDD는 Test Driven Development로, 비즈니스 로직 -> 테스트 케이스 -> 메서드(실제 코드) 순으로 작성한다. 즉 메서드를 검증하기 위한 수단으로 테스트 코드를 작성하는 것이 아니라, 테스트 코드를 통과할 수 있는 소스 코드(메서드)를 짜는 방식으로 작..