Tech Log 🛠️

0. 스터디 진행

팀원들과 일주일에 1~2번 정도 논의하고 싶은 내용과 생각을 정리하는 시간을 가졌다.

스터디는 1시간을 넘기지 않으려고 하였으며 각자 준비한 내용들을 가지고 얘기를 나누는 방식으로 하였다.

1. 켄트백 구현 패턴을 읽기 전에

그동안 코딩을 하면서 추후 변경사항을 고려하거나 변화 비용을 고려하면서 짠 적이 크게 없었다.

그리고 코딩을 하다가 애매한 상황이 오면 그때그때 내키는 것으로 선택을 하였으며 이는 코드의 일관성을 지키기 힘들었고 곧 유지보수 비용이 늘어나기 일쑤였다.

그럼에도 평소에 자바나 객체 지향에 대한 지식을 중요시 했을뿐 코딩을 하다가 필요한 패턴에 대해 고민해보거나 따로 찾아서 공부할 생각은 없었던 것 같다.

때마침 팀에서 객체지향 스터디를 끝내고 다음 책을 고르던 중, 멘토님의 추천으로 "켄트백의 구현 패턴"을 접하게 되었다.

처음에는 단순한 디자인 패턴 책인줄 알았지만 책의 목차를 보고 코드에 여러 도움을 받을 수 있다고 생각을 하여서 이 책으로 스터디를 진행하게 되었다.

2. 읽고나서 느낀 점

책의 도입부부터 "본능에 의한 코딩을 지양하라" 라고 나와있다. 

이 구문에서 이 책이 말하고자 하는 바를 알 수 있었으며 전반적으로 유지보수 비용을 줄여주는 쪽으로 패턴들을 알려주고 있다.

예를 들어서 클래스에 대해서는 다음과 같이 설명하고 있다.

클래스의 로직과 데이터는 함꼐 사용되며 로직은 데이터에 비해 변화율이 낮다. 클래스 내부의 데이터는 
관련 로직에 의해 변화하며, 클래스 내부에서 사용하는 데이터의 변화율은 비슷하다.

평소 클래스의 로직과 데이터에 대해 깊이 고민해본적이 없던 나는 이런 글들을 보고 많은 고민을 할 수 있었으며 코딩을 할때도 패턴들을 생각하면서 코드를 짤 수 있었다.

또한 여러 예제 코드들도 많이 제공을 해주어서 텍스트로만 이해하기 힘들 내용들은 코드를 보면서 쉽게 이해할 수 있었던 것 같다.

코드를 단순히 기술적인 관점이 아닌 "커뮤니케이션"이라고 표현을 한 점도 매우 인상깊었다. 좋은 코드는 커뮤니케이션이 잘 되고 이는 곧 유지 보수 비용을 줄여준다는 말이 나에게 잘 와닿았던 것 같다.

이 책을 읽고 그동안 기능 구현에 급급했던 나는 유지 보수 비용을 고려하면서 코드를 짜기 위해 노력했고 초반에는 설계하는데 시간이 많이 들었지만 , 확실히 나중에 코드를 봤을 때 더 이해하기 쉽고 수정하기 쉽다는 생각이 들었다.

책에서 말해주는 좋은 패턴들이 많기에, 다음과 같이 구현 패턴 책을 읽으면서 하나씩 블로그에 정리해두면서 읽으려고 하였다.

3. 개인적으로 아쉬웠던 점

책의 내용은 전반적으로 좋았지만 아무래도 옛날 책이다보니까,기술이나 자바 코드 같은 부분에서 레거시하다는 느낌을 지울 수는 없었다.

하지만 다르게 생각해보면 옛날 개발자들이 했던 고민들과 그로 인한 발전 방향을 알 수 있었던 시간이었던 것 같다.

그리고 또 다른 아쉬운 점은 번역체가 살짝 어색한 부분이 있어서 이해에 방해가 조금 되었다.

이 부분들은 스터디 팀원들과 함께 문맥을 유추해가면서 의미를 알아맞추는 재미가 있었다.

4. 마무리 회고

비록 클론 코딩 프로젝트 기간이랑 겹쳐서 객체 지향 스터디보다는 시간을 투자하지 못하였던 것 같다.

하지만 틈틈이 책을 보면서 다양한 패턴들을 프로젝트에 적용해볼 수 있어서 좋았고 한층 더 성장했다고 생각한다.

그리고 혼자가 아닌 팀원들과 매주 정해진 시간에 의견을 나누는 것도 책에 대한 다양한 시각을 느낄 수 있어서 좋았던 것 같다.

기술적으로 대단한 뭔가를 알려주는 책은 아니지만 개발자라면 누구나 고민할만한 상황에 특정 패턴을 추천해주는 느낌의 책이라서,

부담없이 읽을 수 있었다.

책에서는 패턴에 대해 다음과 같이 소개한다.

패턴은 지금 당장 무엇을 해야할지를 알려주고, 가치는 사용해야 하는 동기를 알려주며, 원칙은 동기를 행동으로 어떻게 바꿀지를 알려준다.

이처럼 패턴들을 다양한 상황에 대입해보면 충분히 유지보수하기 좋고 이해하기 좋은 코드가 나올 수 있을 것이라고 생각한다.

애그리거트와 트랜잭션

애그리거트에 대해 사용할 수 있는 대표적인 트랜잭션 처리 방식

1. 선점 잠금

2. 비선점 잠금

선점 잠금

애그리거트 사용이 끝날 때까지 다른 스레드가 헤딩 애그리거트를 수정하지 못한다.

ex) agg1이 수정하는 동안 agg2는 잠금이 해제될 때까지 블로킹된다.

선점 잠금 방식을 사용하면 데이터 충돌 문제를 해소할 수 있다.

하지만 교착 상태에 빠질 수 있다.

교착 상태란?

스레드가 각자 다른 애그리거트를 선점하다가 서로의 애그리거트에 접근하는 경우

교착 상태에 바지면 시스템은 마비되며, 사용자가 많을 수록 발생하기 쉽다.

최대 대기 시간을 설정해줌으로써 교착 상태를 해결할 수 있다.

비선점 잠금

변경한 데이터를 실제 DBMS에 반영하는 시점에 변경 가능 여부를 확인

-> 버전 값을 사용한다.

만약 커밋 시에 애그리거트 버전이 다르면 데이터 수정에 실패한다.

하지만 루트 애그리거트 외 다른 엔티티가 변경 되었을 경우, 버전이 그대로인 것을 막기 위해 강제로 버전을 증가시킬수 있다.

오프라인 선점 잠금

여러 트랜잭션에 걸쳐 동시 변경을 막는다.

첫 번째 트랜잭션에서 오프라인 잠금을 선점하고 , 마지막에 잠금을 해제한다.

만약 오프라인 선점 잠금을 하고 해제하지 않는 경우를 대비하기 위해 잠금 유효 시간을 설정해야한다.

필요에 따라서 연장할 수 있다.

도메인 모델과 경계

한 개의 모델로 여러 하위 도메인을 모두 표현하려고 하면 맞지 않는 모델을 만들게 된다.

ex) 카탈로그에서의 상품과 재고 관리에서의 상품은 다른 의미이다.

모델은 특정한 컨텍스트 하에서 완전한 의미를 갖는다.

그러므로 명시적으로 구분되는 경계를 가져서 섞이지 않도록 해야한다.

바운디드 컨텍스트

모델의 경계를 결정하며 논리적으로 한 개의 모델을 갖는다.

실제로 사용자에게 기능을 제공하는 물리적 시스템으로 도메인을 구현한다.

만약 하나의 바운디드 컨텍스트에서 개발할 때는 하위 도메인 모델이 섞이지않도록 해야한다.

바운디드 컨텍스트 구현

바운디드 컨텍스트는 표현 영역 , 응용 서비스 , 인프라를 모두 포함한다.

복잡한 로직을 갖지 않는다면 CRUD 로 구현해도 상관없다.

두 가지 방식을 혼합해서 사용할 수도 있다.

-> CQRS 상태를 변경하는 기능과 쿼리 기능을 구분

도메인 서비스

여러 애그리거트가 필요하고 책임이 애매할 때 도메인 서비스를 이용할 수 있다.

도메인 서비는 다음 상황에 이용된다.

1. 계산로직

2. 외부 시스템 연동이 필요한 로직

도메인 서비스는 상태 없이 로직만 구현한다.

도메인 서비스를 애그리거트 객체에 주입하면 안된다!

외부 시스템 연동과 도메인 서비스

public interface API {
	...
}

도메인 로직 관점에서 인터페이스를 작성해야한다.

응용 서비스는 이 도메인 서비스를 이용해서 기능을 수행한다.

도메인 서비스의 로직이 고정되어 있지 않으면 , 도메인 서비스 자체를 인터페이스로 구현할 수 있다.

도메인 서비스의 구현이 특정 기술에 의존하거나 외부 API를 사용한다면 추상화해야한다.

표현 영역과 응용 영역

응용 영역과 표현 영역은 사용자와 도메인을 연결해주는 매개체 역할이다.

표현 영역은 사용자의 요청을 해석하고 그 기능을 제공하는 응용 서비스를 실행한다.

응용 영역은 실제 사용자가 원하는 기능을 제공한다.

두 영역은 서로 요구하는 파라미터와 형식이 다르기 때문에 요청을 변환해야한다.

사용자가 상호작용은 표현 영역이 처리하기 때문에, 응용 서비스는 표현 영역에 의존하지 않아야한다.

응용 서비스의 역할

사용자의 요청을 처리하기 위해 리포지터리에서 도메인 객체를 가져와 사용한다.

public Result func(Req req){
	// 리포지터리에서 애그리거트를 구함
	Agg agg = AggRepository.finById(req.getId());
    
    // 애그거트의 도메인 기능 실행
    add.doFunc(req.getValue());
    
    // 결과 리턴
    return createSuccessResult(agg)

}

도메인 로직을 도메인 영역과 응용 서비스에 분산해서 구현하면 여러 문제가 발생한다.

1. 코드의 응집성이 떨어진다.

2. 동일한 도메인 로직을 구현할 가능성이 높아진다.

응용 서비스를 구현할 때 몇가지 고려할 사항이 있다.

1. 응용 서비스의 크기

도메인과 관련된 기능을 한 서비스에 넣는다면 클래스가 커지고 관련없는 코드가 뒤섞일 수 있다.

한 응용 클래스에서 한개 내지 2~3개의 기능을 구현하면서 서비스 클래스를 구현하자

2. 인터페이스가 필요한 지

구현 클래스가 여러 개가 아닌 경우, 인터페이스는 불필요하다.

응용 서비스에서 애그리거트 자체를 리턴하면 도메인 로직을 여러 곳에서 실행할 수 있게된다.

따라서 응용 서비스에서는 필요한 데이터만 리턴하는 것이 응집도를 높이는 방법이다.

응용 서비스의 구현

응용 서비스는 표현 영역에 의존하지 않아야한다.

그 이유는 

1. 응용 서비스만 단독으로 테스트하기 어려워진다.

2. 표현 영역의 역할까지 대신하게 된다.

표현 영역의 상태를 응용 서비스에서 변경해버리면 로직을 추적하기 어려워진다. -> 유지보수 비용 증가

이를 위해서 서비스 메서드의 파라미터와 리턴 타입이 표현 영역의 구현 기술을 사용하지 않는 것이다.

표현 영역

1. 사용자가 시스템을 사용할 수 있도록 알맞은 흐름을 제공한다.

2. 사용자의 요청에 맞게 응용 서비스에 기능 실행을 요청한다.

3. 응용 서비스의 실행 결과를 알맞은 형식으로 제공한다.

4. 사용자 세션을 관리한다.

값 검증

원칙적으로 모든 검증은 응용 서비스에서 처리한다.

하지만 각각의 예외를 따로 던질 경우, 사용자는 하나의 이유만 확인할 수 있다.

따라서에러 코드를 모아 하나의 예외로 던질 수도 있다.

표현 영역에서 필수 값과 형식을 검사하면 응용서비스에서는 논리적 오류만 검사하면 된다.

조회 전용 기능과 응용 서비스

응용 서비스가 사용자 요청 기능을 실행하는 데 별다른 기여를 하지 못한다면 굳이 서비스를 만들지 않아도 된다.

애그리거트

객체 모델이 복잡해지면 개별 구성요소 위주로 모델을 이해하게 되고 전반적인 구조나 큰 수준에서 도메인 간의 관계를 파악하기 어려워진다.

-> 상위 수준에서 모델을 조망해야하는데 , 애그리거트를 사용할 수 있다.

애그리리거트는 복잡한 도메인을 단순한 구조로 만들어준다.

애그리거트에 속한 객체는 유사하거나 동일한 라이프 사이클을 가지며 다른 애그리커트에 속한 객체는 다른 애그리커트에

속하지 않는다.

애그리거트 루트

애그리거트 전체를 관리할 주체가 필요한데, 이 책임을 지는 것이 루트 엔티티이다.

ex) Order -> (OrderLine) , (Orderer) , (Address)

핵심 역할은 애그리거트의 일관성이 깨지지 않도록 하는 것이다.

루트는 애그리거트가 제공해야할 도메인을 구현한다.

애그리거트 외부에서 애그리거트에 속한 객체를 직접 변경하면 안된다.

Info info = order.info();
info.setAddress(newAddress);

도메인 모델에 대해 다음 두가지를 지켜야한다.

1. 단순한 set 메소드를 공개 범위로 만들지 않는다.

2. 밸류 타입은 불변으로 한다.

잠금 대상이 많아진다는 것은 그만틈 동시에 처리할 수 있는 트랜잭션 개수가 줄어든다는 것이다. 

-> 성능의 저하

한 트랜잭션 내에서는 한 개의 애그리거트만 수정해야한다.

한 애그리거트가 다른 애그리거트의 기능에 의존하기 시작하면 애그리거트 간 결합도가 높아진다.

리포지터리와 애그리거트

객체의 영속성을 처리하는 리포지터리는 애그리거트 단위로 존재한다.

애그리거트 전체를 저장소에 영속화해야한다.

ID를 이용한 애그리거트 참조

애그리거트에서 다른 애그리거트를 참조한다는 것은 애그리거트의 뤁트를 참조한다는 것과 같다.

애그리거트를 직접 참조할 때 가장 큰 문제는 편리함을 오용할 수 있다는 것이다.

-> ID를 사용해서 다른 애그리거트를 참조하자

ID를 사용해서 참조하면 모든 객체가 참조로 연결되자 않고 한 애그리거트에 속한 객체들만 참조로 연결된다.

애그리거트를 팩토리로 사용하기

애그리거트가 갖고 있는 데이터를 이용해서 다른 애그리거트를 생성해야 한다면 다른 애그리거트에 팩토리 메소드를 구현하는 것을 고려해보자

네 개의 영역

표현 영역

HTTP 요청을 필요로 하는 형식으로 변환해서 응용 영역에 전달하고 다시 응답을 HTTP 응답으로 변환하여 전송

ex) mvc 프레임워크

응용 영역(서비스 계층)

도메인 영역의 모델을 사용해서 사용자에게 제공하는 기능을 구현한다.

로직을 직접 수행하기 보단 도메인 모델에 로직 수행을 위힘

도메인 영역

도메인 모델을 구현하고 핵심 로직을 구현

public cancelOrder(String orderId) {
	Order order = findOrderById(orderId); // 도메인 모델에 위임
    ...
}

인프라 스트럭쳐 영역

논리적 개념 보다는 구현 기술을 다룬다.

ex) DB ,SMTP , 카프카

계층 구조 아키텍처

아키텍처는 보통

표현 -> 응용 -> 도메인 -> 인프라스트럭쳐 로 이루어져있다.

상위 계층은 하위 계층에 의존할 수 있지만 그 반대는 존재하지 않는다.

꼭 바로 아래 계층에만 의존하지 않고 유연적으로 의존성을 가져가기도 한다.

ex) 응용 -> 인프라

하지만 이 경우 두 가지 문제가 생긴다

1. 구현 설정을 모두 끝내야하기 때문에 테스트가 어려움 

2. 구현 방식을 변경하기 어려움

따라서 DIP를 적용하면 위의 문제를 해결할 수 있다.

DIP

고수준 모듈

- 의미 있는 단일 기능을 제공하는 모듈

- 여러가지 하위 기능이 필요하다

저수준 모듈

- 고수준 모듈의 하위 기능을 구현 

ex) JPA , Drools

고수준 모듈이 저수준 모듈에 의존하면 앞서 말한 두가지 문제가 생긴다.

그래서 DIP는 저수준 모듈이 고수준 모듈에 의존하도록 바꾼다.

이때 추상화한 인터페이스를 사용한다.

인터페이스를 통해 더 이상 고수준 모듈이 저수준 모듈에 의존하지 않는다.

이를 의존 관계 역전(DIP)라고 한다.

DIP를 통해 두 가지 문제를 해결할 수 있다.

1. 기술 교체를 쉽게 할 수 있다.

// 사용할 저수준 객체 생성
Rule Discounter ruleDiscounter = new DroolsRuleDiscounter();

// 생성자 방식으로 주입
CalculateDiscountService disService = new CalculateDiscountService(ruleDiscounter);

2. 테스트가 용이하다.

기존에는 기술이 구현되어야 할 수 있었지만 이젠 대역객체(mock)을 이용해서 간편하게 진행할수 있다.

스텁이나 모의 객체와 같은 테스트 목적의 대역을 사용하여 거의 모든 상황을 테스트할 수 있다 !

* 인터페이스를 설계할 때 저수준 모듈에서 추출하지 않아야한다 !!

* 하위 기능을 추상화한 인터페이스는 고수준 모듈 관점에서 도출한다 !!

도메인 영역의 주요 구성요소

엔티티

- 고유의 식별자를 가지고 도메인의 고유한 개념을 표현한다.

밸류

- 개념적으로 하나인 값을 표현

ex) 주소 , 금액

애그리거트

- 연관된 엔티티와 밸류 객체를 개념적으로 묶은 것

리포지터리

- 도메인 모델의 영속성을 처리한다.

도메인 서비스

- 특정 엔티티에 속하지 않은 도메인 로직

- 도메인 로직이 여러 엔티티와 밸류를 필요로 하면 도메인 서비스에서 로직을 구현한다.

도메인 엔티티 VS DB 엔티티

도메인 엔티티

- 데이터와 함께 도메인 기능을 제공한다.

- 도메인 관점에서 기능을 구현하고 캡슐화해서 데이터가 임의로 변경되는 것을 막는다.

- 개념적으로 하나인 경우 밸루 타입을 이용해서 표현할 수 있다.

애그리거트

- 개별 객체뿐만 아니라 상위 수준에서 모델을 볼 수 있어야 전체 모델의 관계와 개별 모델을 이해하는 데

도움이 된다.

- 관련 객체를  하나로 묶은 군집

- 객체 군집 단위로 모델을 바라본다.

- 루트 엔티티는 에그리거트에 속해 있는 엔티티와 밸류 객체를 이용해서 구현해야할 기능을 제공한다.

- 루트 엔티티를 통해 다른 엔티티나 밸류 객체에 접근한다.-> 캡슐화

리포지터리

- 애그리거트 단위로 객체를 저장하고 조회하는 기능을 정의한다.

- 도메인 모델을 사용해야 하는 코드는 리포지터리를 통해 도메인 객체를 구한 뒤에 도메인 객체의 기능을 사용

요구 사항

요구사항을 올바르게 이해하지 못하면 엉뚱한 기능을 만들게 된다.

(Garbage in , Garbage out)

-> 코딩에 앞서 요구사항을 올바르게 이해하는 것이 중요하다 !

도메인 모델

특정 도메인을 개념적으로 표현한 것을 도메인 모델이라고 한다.

도메인 모델을 사용하면 여러 관계자들이 동일한 모습으로 이해할 수 있으며, 여러가지 종류로 모델링 할 수 있다.

ex) 객체 , 상태 다이어그램, 그래프

도메인 모델 패턴

도메인 계층은 도메인의 핵심 규칙을 구현한다.

아래의 코드는 주문 상태에 따라 배송지를 변경할 수 있는 가에 대한 코드를 도메인 모델 패턴으로 구현

public class Order {
	private OrderState state;
    private ShippingInfo info;
    
    public void changeShippingInfo(ShippingInfo info) {
    	if(!state.isShippingChangeable()) {
        	// 예외처리
        }
        ...
    }
    ...
}

public enum OrderState {
	PAYMENT_WAITING {
    	public boolean isShippingChangeable() {
        	return true;
        }
    }
    ...
}

혹은 이렇게도 구현할 수 있다.

public class Order {
	private OrderState state;
    private ShippingInfo info;
    
    public void changeShippingInfo(ShippingInfo info) {
    	if(!state.isShippingChangeable()) {
        	// 예외처리
        }
        ...
    }
    
	private boolean isShippingChangeable() {
    	return state == OrderState.PAYMENT_WAITING || ...
    }
    ...
}

public enum OrderState {
	PAYMENT_WAITING
    ...
    ;
    
}

중요한 점은 Order , OrderState 같은 주문 도메인 모델에 구현 했다는 점이다.

이렇게 함으로써 요구사항이 변경되더라도 다른 코드에 영향을 덜 줄 수 있다.

도메인 모델 도출

구현을 시작하려면 도메인에 대한 초기 모델이 필요하다.

몇가지 요구사항으로 부터 구현해야할 기능과 데이터를 알 수 있다.

ex)

최소 한 종류 이상의 상품 주문 -> 로직 구현 필요

한 상품을 한 개 이상 주문할 수 있다. -> 구매 상품 정보는 상품 개수를 포함한다

엔티티

엔티티의 가장 큰 특징은 식별자를 가지는 것이다.

식별자는 엔티티가 생성되고 속성을 바꾸고 삭제할 때까지 바뀌지 않는다.

즉 식별자가 같으면 같은 엔티티이다.

식별자는 사용하는 도메인의 특징과 사용하는 기술에 따라 달라지며, DB에서 생성해주기도 한다.

(이 경우 DB에 저장해야 알 수 있음)

밸루(value) 타입 

개념적으로 완전한 하나를 표현할 때 밸루 타입을 사용할 수 있다.

private String receiverName;
private String receiverPhoneNumber;

//다음과 같이 표현 가능
private Receiver receiver;

무조건 두 개 이상의 필드를 가져야 하는 것은 아니다.

public class Money {
	private int value;
    
    public Money(int value) {
    	this.value = value;
    }
}

다음과 같이 정수형의 value를 Money 로 표현함으로써 의미를 명확하게 할 수 있다.

또한 해당 클래스 내에 더하기 , 곱하기 같은 비즈니스 로직을 추가할 수 있다.

밸루 타입은 안전한 코드 작성을 위해 불변으로 표현한다.

*불변 : 데이터 변경 기능을 제공하지 않음

도메인 모델이 set 메소드를 넣지 않는 이유

1. 핵심 개념이나 의도를 코드에서 사라지게 한다.

// 도메인과 의도가 명확함
public void completePayment();

// 필드값만 변경하고 끝, 의도가 명확하지 않음
pubic void setStatus();

2. 도메인 객체를 생성할 때 온전하지 않는 상태가 될 수 있다.

Order order = new Order();

// set 메소드로 값을 전달
order.setOrderLines(lines);

만일 위와 같이 set 메소드로 값을 전달한다면 나중에 필드가 null인지 검사하는 코드가 필요하다.

하지만 생성할 때부터 모든 데이터를 받는다면 생성하는 시점에 검사하면 되므로 해당 로직이 필요가 없어진다.

도메인 용어와 유비쿼터스 언어

도메인 용어를 코드에 반영하지 않는다면 해석하는데 부담이 된다.

// 도메인 용어가 반영되지 않음
public OrderState {
	STEP1,STEP2,STEP3,STEP4;
}

// 도메인 용어가 반영되서 직관적임
public OrderState {
	PAYMENT_WAITING,PREPARING,SHIPPED,DELIVERING;
}

도메인 용어에 알맞은 단어를 찾는 시간을 아까워하지 말자!

컬렉션

컬렉션 인터페이스는 여러 객체의 묶음에 대해 제각각 다른 의미를 전달한다.

주로 성능에 관련된 프로그래머의 의도를 전달한다.

컬렉션이 표현하는 3가지 개념

1. 크기

- 배열의 크기는 생성 시 고정되지만, 대부분의 컬렉션은 중간에 크기를 수정할 수 있다.

2. 원소 간 순서

- 원소의 순서에 대한 정보가 필요하다면 순서를 보전하는 컬렉션을 사용해야한다.

3. 독자성

- 일부 연산의 경우 어떤 원소가 컬렉션에 속해있는 지 혹은 몇번 나타났는지 중요한 경우가 있다.

인터페이스

배열

가장 단순한 인터페이스이다.

유연성 문제를 제외하고 성능이 중요한 경우에 사용한다.

Iterable

원소를 주가하는 것은 막을 수 있지만 원소가 지워질 위험이 있다.

Collection

Iterable을 상속하며 여러 메소드를 추가로 지원한다.

*선언을 일반적인 인터페이스로 남겨두면 구현 클래스를 쉽게 바꿀 수 있다.

List

Collection을 기반으로 해서 원소 간에 정해진 순서를 부여한다.

인덱스를 통해 어떤 원소를 접근할 수 있다.

Set

중복을 허용하지 않는다.

SertedSet

순서는 유지되지만 중복 원소가 없는 컬렉션이다.

메시지

메시지 수신자가 메시지를 받으면, 발신자의 상태는 바뀌지 않지만 수신자의 상태는 바뀔 수 있다.

메시지를 사용하는 프로시저는 당장 중요하지 않은 세부 구현이 존재한다 라는 의미를 내포할 수 있다. (캡슐화)

function() {
	input();
    process();
    output();
}

선택 메시지

선택 메시지를 사용하면 명시적 조건문의 사용을 크게 줄일 수 있다.

하지만 과도한 선택메시지의 사용은 가독성을 저해할 수 있다.

public void display(Subject subject, Brush brush) {
	brush.display(subject);
}

더블 디스패치

2개의 선택 메시지를 직렬로 연결할 수 있다.

https://www.youtube.com/watch?v=s-tXAHub6vg&loop=0 

분리 메시지

여러 단계로 구성되는 복잡한 알고즘을 단계별로 모으로 메시지를 보낼 수 있다.

되돌림 메시지

도우미 메소드를 사용하면 메소드의 가독성을 높일 수 있다.

void process() {
	helper.process(this);
}

void compute() {
	input();
    process(helper);
    output();
}

초청 메시지

로직에 대한 기본 구현되어있지 않다면 추상 메소드로 선언해서 추상 메시지임을 분명히하라

설명 메시지

highlight 메소드와 같이 프로그래머의 의도를 전달하기 위한 메소드가 있을 수 있다.

highlight() {
	reverse();
}

또 주석을 붙이고 싶은 코드는 다음과 같이 변경 가능하다,.

flags |= LOADED_BIT; // 로드 비트를 설정

setLoadedFlag() {
	flags |= LOADED_BIT;
};

이러한 한줄짜리 메소드는 커뮤니케이션을 돕는다.

예외 흐름

예외 흐름은 수행 빈도가 낮고 수정 빈도가 낮으며, 주요 흐름에 비해 커뮤니케이션의 중요성이 떨어진다.

주료 흐름은 명료하게 나타내고 예외 흐름은 주요 흐름의 명료성을 훼손하지 않는 범위 내에서 명료하게 나타내라 !

보호절

보호절을 사용해서 복잡한 제어 구조를 사용하지 않고 같은 코드를 표현할 수 있다.

void conpute() {
	Server server = getServer();
    if (server != null) {
    	Client client = server.getClient();
        if(client != null) {
        	....
        }
    }
}

void conpute() {
	Server server = getServer();
    if (server != null)
    	return;
    Client client = server.getClient();
    if(client != null)
    	return;
    ...
}

예외

메소드가 예외를 던지면 메소드의 설계와 구현의 영향을 미친다.

따라서 가능하면 순차적 구문 , 메시지 , 루프 제어문을 사용해서 제어 흐름이 안될 경우 예외를 사용하는 것이 좋다

예외 전달

하위 수준의 예외는 문제를 진단하는 데 유용한 정보를 제공해주는 경우가 많다.

하위 수준의 예외를 상위 수준 예외로 포장하라 

객체는 외부에 드러나는 행위와 행위를 지원하기 위한 상태를 묶어주는 편리한 단위다.

상태

-  상태를 효과적으로 관리하기 위해서 유사한 상태를 묶어서 관리하고 각 상태는 별도로 관리해야한다.

두 개의 상태가 유사한 지 알려면

1. 두 개의 상태가 동일한 연산 안에서 사용되는가?

2. 동일한 시점에 생성되고 소멸되는가?

를 확인하면 된다.

직접 접근

- 직접 접근의 장점은 명확성이다.

x=10 // 매우매우 명확하다.

하지만 코드를 통해 자세한 내용을 알려주기는 어렵다.

예를 들어

doorRegister = 1; // 직관적이지 않음
door.open(); // 매우 직관적임

따라서 직접 접근이 많다면 원활한 커뮤니케이션을 방해할 수 있다.

간접 접근

- 명확성과 직접성을 희생해서 유연성을 얻을 수 있다.

- 2개 이상의 데이터 간의 의존 관계가 존재하는 경우 매우 유용하다.

void setValue(int number){
	this.number = number;
    value = width * number;
}

공용 상태

- 같은 데이터 요소는 클래스에 필드를 선언해서 사용하면 좋다.

- 각 객체의 공용 상태는 모두 범위와 생명 기간이 같아야한다.

class Point {
	int x;
    int y;
}

가변 상태

- 데이터 요소의 이름을 키로하고 값을 데이터로 하는 맵으로 표현한다.

- 유연하긴 하지만 커뮤니케이션이 어렵다.

- 각 필드의 상태에 따라 다른 필드를 필요로 하는 경우 유용하다.

외재 상태

어떤 객체와 관련된 특수 목적 정보는 객체가 아니라 필요로 하는 부분에 두는 게 낫다.

다만 외재 상태를 사용하면 객체의 복사가 어려워진다.

변수

대부분의 경우에는 지역 변수를 시용하고 간간히 정적 변수와 전용 변수를 사용해서 객체 간의 의존성을 줄이는 것이 좋다.

변수의 종류를 줄이면 문맥만으로도 쉽게 구분할 수 있다.

변수의 생명 시간은 변수의 범위에 가까운게 좋다.

같은 범위에서 정의되는 변수들은 모두 같은 생명 기간을 가져야한다.

지역변수 

지역 변수는 가급적 최소 범위 내에서 선언하라

지역 변수는 도우미 메소드로 바꿀 수 있다.

이때 연산에 필요한 표현은 메소드 내용이 되고, 변수 이름은 메소드 이름이 된다.

필드

필드의 범위와 생명기간은 필드를 가지고 있는 객체와 같다.

만약 필드를 가장 앞에 선언하면 , 어떻게 사용될지에 대한 문맥을 제공해줄 수 있다.

뒤에 선언한다면 중요성이 상대적으로 떨어진다는 것을 암시한다.

불린 플래그를 통해 "객체가 두 가지 다른 방식으로 동작한다" 는 것을 내포할 수 있다.

파라미터

하나의 객체에서 다른 객체에 대한 여러 메시지가 같은 파라미터를 필요로 한다면 , 파라미터를 호출되는 객체에 포함하라

Server s = new Server();
s.a(this);
s.b(this);
s.c(this);

이 코드를 다음과 같이 변경할 수 있다.

Server s = new Server(this);
s.a();
s.b();
s.c();

이렇게 함으로써 의존성을 줄일 수 있다.

옵션 파라미터

반드시 필요한 파라미터를 앞에서 전달하고 , 옵션 파라미터는 뒤에 전달한다.

public Server();
public Server(int port);
public Server(int port, int log)

이를 망원경식 파라미터 패턴이라고도 한다.

가변 인자

아래와 같은 방법으로 임의의 수의 인자를 사용하여 메소드를 호출할 수 있다.

method(Class... classes)

파라미터 객체

여러 개의 파라미터가 함께 여러 메소드로 전달된다면, 이들을 하나로 묶어서 하나의 객체로 만들 수 있다.

예를 들어 x,y,heigh,width 를 묶어서 파라미터로 만들 수 있다.

setOuterBounds(x, y, width, height)

setOuterBounds(bounds)

파라미터 객체를 사용하면 코드가 짧아지고 의도를 명확히 전달할 수 있다.

또한 해당 파라미터들이 밀접한 연관성을 가지고 있다는 것을 보여줄 수 있다.

하지만 만약 객체의 생성으로 인해 성능 저하가 일어난다면 파라미터 객체를 없애는 쪽으로 수정하면 된다.

상수

변화하지 않는 데이터를 static final을 통해 선언하고 그 변수를 참조하게끔 하는 것이 좋다.

초기화

초기화는 변수가 사용되기 전에 알고 있는 상태로 만드는 작업이다.

초기화는 가급적 선언과 함께 하는 것이 좋다.

만약 초기화에 드는 비용이 비싸다면 생성과 초기화를 분리하는 것이 좋다..

열성적 초기화(eager)

모든 변수가 초기화 이후에 사용되는 것을 보장할 수 있다.

변수가 선언되거나 생성되자마자 초기화한다.

선언문에서 변수를 초기화하면 선언 타입과 실제 타입을 쉽게 확인할 수 있다.

List<Integer> number = new ArrayList<>();

선언문에서 필드를 초기화할 수 없다면 생성자에서 초기화하라

class Point {
	int x,y;
    Point(int x,int y){
    	this.x = x;
        this.y = y;
    }
}

게으른 초기화(lazy)

초기화 비용이 크거나 비용 부담을 늦추고 싶다면 메소드가 호출될 때 객체를 초기화하면 된다.