1.1 -er 로 끝나는 이름을 사용하지 마세요. 토론하기 : http://goo.gl/Uy3wZ6 1. 클래스는 팩토리이다. 저자는 책에서 클래스를 객체의 팩토리로 설명하고 있다. 객체지향의 사실과 오해를 읽으면서 타입과 클래스의 차이에 대해 고민해 본적이 있고,
상태 없는 객체는 존재해서는 안되고, 상태는 객체의 식별자여야 한다.객체지향의 사실과 오해는 상태만 있는 것을 값객체로 보고 식별 가능한 식별자가 따로 존재해야 한다고 하였다.(entity 관점) 하지만 저자는 상태 그 자체들을 객체의 식별자로 보았다.(equals 오
이상적인 코드는 스스로를 설명하기 때문에 어떤 추가 문서도 필요하지 않다.코드 자체만으로 의미가 명확하게 전달된다.나쁜 설계가 문서를 작성하도록 강요한다.추가로 저자는 단위테스트 도한 클래스의 일부로 취급해야 한다고 한다.하지만 대부분의 언어가 불가능하기 때문에 Cas
객체를 가능한 작고 응집력 있게 유지해야 유지보수와 테스트에 유익하다는점에 동의합니다.절차지향 프로그래밍 : 위에서 아래로 로직이 수행되며 직접 명령(요청)을 내린다.선언형 프로그래밍 : 정의(is-a) 를 하고 제어를 위임한다.정적 메서드는 클래스를 정의하여 제어를
저자는 상태를 가지는 class 를 get set 을 통해 상태를 노출시키는 가변객체를 진짜 클래스가 아닌 단순한 자료구조로 바라본다객체와 자료구조의 차이는 무엇인가?객체는 객체 사이에 메세지를 주고 받고 자신의 상태를 캡슐화 한다.(불투명박스)하지만 자료구조는 어떠한
1. 계층형 아키텍처이란 계층형 아키텍처 : 웹 -> 도메인 -> 영속성 웹 : 요청을 받는다 도메인 : 비지니스 계층에 있는 서비스로 필요한 로직을 수행한다. 영속성 : 도메인 엔티티의 상태를 조회하거나 변경하는 부분 특징 견고한 아키텍처 패턴 웹 계층이나 영속성
SRP : 하나의 컴포넌트는 오로지 한 가지 일만 해야 하고, 그것을 올바르게 수행해야 한다.(X)좋은 조언이지만 SRP 의 실제의도는 아니다다음이 SRP 의 실제 정의이다.SRP : 컴포넌트를 변경하는 이유는 오직 하나뿐이어야 한다.(O)책임은 1가지 일만 하는 것
패키지 구조를 먼저 작성해야 한다. 한 패키지에 있는 클래스들이 불러오지(import) 말아야 할 다른 패키지에 있는 클래스들을 불러오는 상황을 방지해야 한다. 1. 계층으로 구성하기 계층으로 코드를 구성하면, 기능적인 측면들이 섞이기 쉽다 문제점 문제1 : 애플리케
포트 : 인터페이스어댑터 : 포트의 구현체인커밍 어댑터 : 외부로부터 요청을 내부로직 수행아웃고잉 어탭터 : 내부에서 외부로 데이터 전달"헥사고날 아키텍처는 포트와 어댑터로도 알려져 있다. 외부 타입마다 어탭터가 존재하고, 외부 영역은 애플리케이션의 API(Applic
왜 유스케이스와 어탭터를 그냥 필요할 때 인스텅스화하면 안 되는 걸까?코드 의존성이 올바른 방향을 가리키게 하기 위해서이다(안쪽으로, -> 도메인 방향)만약 유스케이스가 영속성 어탭터를 호출해야 하고, 스스로 인스턴스화한다면 의존성의 방향이 잘못된것이다.이것이 바로 아