Tech Log 🛠️

0. 스터디 진행

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

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

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

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

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

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

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

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

2. 읽고나서 느낀 점

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. 마무리 회고

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

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

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

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

부담없이 읽을 수 있었다.

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

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

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

컬렉션

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

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

컬렉션이 표현하는 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)

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

클래스

내부 클래스

작은 전용 클래스를 사용하면 클래스 사용에 대한 비용을 지불하지 않고 클래스의 장점을 취할 수 있다.

내부 클래스는 내부 클래스를 감싼 클래스에 대한 정보를 암묵적으로 전달받는다.

명시적으로 클래스 간의 관계를 정하지 않으면서도 감싼 클래스의 데이터를 접근할 수 있다.

public class Enclose {
	private String field;
    
    public class Inner {
    	public String example() {
        	return field;
        }
     }

}

만약 외부 클래스와 완전히 분리된 내부 클래스를 사용하려면, 내부 클래스를 정적으로 선언하면 된다.

인스턴스별 행위

객체의 로직이 클래스에 의해 완전히 정의될 때, 코드 독자는 어떤 일이 벌어지는지 이해한다.

하지만 인스턴스 별로 로직이 다르다면 코드를 쉽게 이해할 수 없다.

효과적인 프로그래밍을 위해 인스턴스 생성 후에는 인스턴스 별 행동을 변화시키지 않는 것이 좋다.

조건문

조건물을 사용하면 인스턴스 별 행동을 지원하면서도 모든 로직을 하나의 클래스 안에 넣을 수 있다.

히자민 프로그램 수행 경로가 많으면 많을 수록 오류가 생길 확률이 높아진다.

아래와 같은 스위치 문을 생각해보자

public boolean contains(Point p) {
	switch (getType()) {
    	case A :
        // ...
        case B :
        // ...
    }
}

여기서 case C 를 추가하고 싶다면 , 스위치문에 새로운 절을 삽입하고 클래스 또한 수정해야 할수도 있다.

따라서 하위 클래스나 위임 중 하나를 선택해서 조건문을 메세지로 바꾸는 것으로 해결할 수 있다.

위임

위임을 통해서 각 인스턴스앳서 다른 로직을 수행하게 할 수 있다.

공통으로 사용되는 로직은 위임 클래스를 참조하는 클래스에 들어있지만 , 변형은 여러 객체에 각각 구현된다.

public void mouseDown() {
	getTool().mouseDown();
}

플러그인 선택자

한두개의 메소드에서만 인스턴스별 행동이 필요한 경우 리플렉션을 통해 메소드를 호출하는 것도 좋다

String name;
public void runTest() throws Exception {
	Class[] noArgument = new class[0];
    Method method = getClass().getMethod(name,noArguments);
    method.invoke(this,new Object[0]);
}

익명 내부 클래스

익명 내부 클래스는 한곳에서만 사용되는 클래스를 생성해서 오버라이드 한 후에 지역적으로만 사용하는 것이다.

이때 클래스 이름은 지정하지 않는다.

효율적인 사용을 위해 API가 매우 간단하거나 상위 클래스가 대부분의 구현을 담당해서 내부 클래스를 쉽게 구현할 수 있어야한다.

익명 내부 클래스를 사용하려면 클래스를 생성할 때 인스턴스에서 사용할 코드를 알아야한다.

또한 테스트하기 어려워서 복잡한 로직에 적절치않다.

클래스

클래스는 비슷한 성질을 가진 것을 총칭하며, 객체는 클래스가 구체화된 것이다.

클래스

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

대체로 이 선언을 내포하기는 하지만 절대적이지는 않다.

따라서 효과적인 프로그래밍을 위해서 로직을 클래스 단위로 어떻게 구성해야 하난지, 로직 사이의 차이점을 어떻게 효과적으로 

표현해야하는지 배워야 한다.

클래스 계층을 사용하면 하위 클래스를 이해하기 위해 상위 클래스 또한 모두 이해해야 하므로 읽기 어려워진다.

모든 클래스를 상속받기 보단 선별적으로 클래스를 상속하자

클래스는 프로그램의 설계 요소 중 값이 비싼 편이므로, 의미 있는 작업에만 클래스를 사용해야한다.

다른 클래스의 크기를 유지하면서 클래스의 수를 줄이는 것이 프로그램을 개선한 것이라고 볼 수 있다.

단순한 상위 클래스 이름

적합한 클래스 이름은 코드를 단순화하고 향상 시켜준다.

중요한 클래스 이름에 대해서는 한 단어로 된 이름을 사용하고 , 메타포(은유)를 사용하면 좋다 !

한정적 하위클래스 이름

하위클래스 이름은 상위 클래스와 달리 간결성은 포기하더라도 표현성을 택하는 것이 좋다.

하지만 그 하위클래스가 다른 클래스의 상위 클래스라면 다시 단순성을 선택해야한다.

다른 경우는 다단계 클래스 계층이다. 

기계적으로 바로 위의 상위 클래스 이름에 수식어를 붙이기 보단 , 가장 유사한 상위 클래스의 이름을 바탕으로

짓는 것이 좋다.

효과적인 커뮤니케이션을 위해 좋은 클래스 이름이 필요하다.

이름에 연관성이 없는 클래스는 이해하기도 기억하기도 어렵다.

클래스 이름은 코드의 내용을 반영해야한다.

추상 인터페이스

설계상의 결정을 필요 이상으로 노출하지 않아야한다.

인터페이스란 구현이 빠진 여러 연산의 집합을 의미한다.

하지만 인터페이스 추가에는 비용이 발생한다.

따라서 유연성을 얻을 수 있는 경우에만 추가 설계에 대한 비용을 지불해야한다.

실제로 유연성이 필요하지 않는 경우도 매우 많다.

저번 장에도 말했듯이 불확실한 미래를 예측하기 보단 당장의 이익을 취하자

추후 필요해지는 경우에만 시스템에 유연성을 부여하는 편이 바람직하다.

인터페이스

자바 인터페이스를 사용하는 것은 "여기까지가 내가 원하는 것이고 , 이외의 내용은 상관하지 않는다."

라는 내용을 내포한다.

인터페이스는 필드를 배제하고 연산만을 나타내므로 사용자는 구현이 변경되더라도 신경 쓸 필요가 없다.

반대로 구현을 바꾸는 것은 쉽지만 인터페이스 자체를 변경하는 것은 쉽지 않다.

변경 시에 모든 구현 클래스를 수정해야하기 때문이다.

버전 인터페이스

만약 인터페이스를 바꾸고 싶은데 설계를 수정하는 것이 부담스러운 경우, 버전 인터페이스를 사용할 수 있다.

이렇게 하면 기존 인터페이스를 생속헤서 새로운 연산을 추가하므로 사용자는 기존 인터페이스에 대해 알 필요가 없다.

하지만 버전 인터페이스는 그리 좋은 방법이 아니다.

버전 인터페이스가 늘어날 수록 결국 관리해야할 로직,클래스가 많아지므로 클라이언트가 할 일이 늘어난다.

이는 설계 자체를 수정할 때가 되었다는 것이다.

추상 클래스

추상 인터페이스를 구현하는 또 다른 방법은 추상 클래스를 사용하는 것이다.

인터페이스와 비교했을 때 장단점이 있다.

먼저 수정의 관점에서 보면 추상 클래스는 수정에 용이하다.

기존 설계를 유지하면서 얼마든지 새로운 연산을 추가할 수 있다.

하지만 추상 클래스는 단 1개의 상위 클래스만을 지정할 수 있다.

이는 여러 개의 인터페이스를 구현할 수 있는 것과 대조된다.

자바 클래스에서 abstract 키워드를 씀으로써, 해당 클래스를 사용하기 위해서는

반드시 구현이 필요하다는 사실을 전달할 수 있다.

값 객체

함수형(값) 스타일 연산은 상태를 변화시키지 않으며 새로운 값을 생성한다.

고정적인 상황을 표현하고 함수형 스타일이 적절하고 , 상황이 변하는 경우라면 상태를 사용하는 편이 낫다.

값 스타일 객체의 문제점은 성능이다.  (하지만 매우 미비하다)

다른 문제는 값 스타일과 상태로 부분을 구별하기 쉽지 않다는 것이다.

따라서 두 스타일을 적절히 섞어서 사용하는 것이 좋다.

특화

연산 간의 유사점과 차이점을 부각시키는 방향으로 코드를 작성하면 , 프로그램을 읽고 수정하기 쉬워진다.

이런 방식을 사용하면 명확히 코드를 이해하고 새로운 요구 사항을 처리할 수 있을 지를 알 수 있다.

또한 수정이 필요한 경우 기존 코드를 변형할지 새로 만들지를 판단할 수 있다.

대부분의 프로그래밍은 두 가지의 극단적 변형 사이에 존재한다.

현실에서는 약간 변형된 입력 데이터를 시용하거나 약간 변형된 로직을 사용하는 경우가 많다.

하위 클래스

제대로 된 상위클래스를 가지고 있다면 하위 클래스는 강력한 힘을 발휘할 수 있다.

하지만 하위 클래스의 사용은 여러 문제를 야기한다.

1. 하위 클래스의 사용을 되돌리기 어렵다.

2. 하위클래스를 이해하기 위해 상위 클래스까지 이해해야한다. 

3. 상위 클래스의 수정이 조심스러워진다.

이러한 문제점을 잘 알고 있다면 하위 클래스는 강력한 도구가 될 수 있다.

상위 클래스의 로직을 여러 개의 메소드로 잘게 쪼개면 각 메소드를 따로 오버라이드 할 수 있다.

하위 클래스는 동적으로 변화하는 로직을 나타낼 수 없다.

따라서 이 경우네는 조건문이나 위임을 사용하는 것이 바람직하다. 

구현자

객체지향 프로그램에서는 다형적 메시지를 통해 선택을 표현할 수 있다.

덕분에 연산의 내부 구현에 대해서는 신경 쓰지 않아도 된다.

다형적 메세지는 여러 가지 변경을 수용할 수 있다.

프로그램이 다른 시스템에 일련의 데이터를 전송하는 경우, 추상 클래스를 사용하면 호출 코드에 영향을 주지 않고

구현을 자유롭게 바꿀 수 있다.

이는 효과적으로 프로그래머의 의도와 구현을 분리할 수 있다.

또한 상상하지 못했던 미래의 확장을 수용할 수 있다.

프로그래밍 이론

프로그래밍 이론은 새로운 문제가 발생해도 해결책을 찾을 수 있도록 도와준다.

실제 프로그래밍에서는 동력이 존재한다.

1. 가치

- 가치는 모든 프로그래밍에 적용된다. 

- 커뮤니테이션 , 유연성 등 모든 의사 결정에 영향을 미친다.

2. 원칙

- 직접 적용하기 어려운 가치와 , 지엽 적인 패턴 사이에 가교 역할을 한다.

- 패턴 중 하나를 선택해야 할 때 원칙을 따른다. 

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

가치

세가지 가치는 서로 충돌하는 경우도 있지만 상호 보완적인 경우가 많다.

커뮤니케이션

다른 개발자가 봤을 때의 관점으로 코드를 작성하라

코드를 쉽게 이해하고, 수정하고, 사용할 수 있어야한다

이렇게 작성하면 추후 코드 수정 시에 내가 쓴 코드를 쉽게 이해할 수 있으므로, 개발 비용이 감소한다.

또한 타인의 시선에서 생각하다보면 더 많은 생각을 하기 때문에 코드의 질이 좋아진다.

단순성

불필요한 복잡도는 소프트웨어의 수정을 어렵게 하기 때문에 프로그램의 가치가 떨어진다.

코드에서 불필요한 부분을 제거하라. 

과도한 요소와 의미없는 코드를 제거하면 프로그램의 단순성을 높일 수 있다.

커뮤니케이션과 단순성은 협업 관계에 있다.

커뮤니케이션의 신경을 쓸수록 어떤 부분이 과도하게 복잡한 지 알기 쉬우며, 단순할수록 시스템을 이해하기 쉽다.

유연성

유연성을 위해서 복잡한 설계를 정당화할 수 있다.

하지만 이러한 복잡도가 아무런 이득을 가져오지 않는다면 단순성을 선택해야한다.

설계 초기 유연성이 필요했다고 생각하도, 이후 필요한 상황이 오지 않을 수 있다.

그렇기 때문에 초기 설계 비용을 불필요하게 증가시키는 것보다 당장의 이득을 선택하는 것이 좋다.

추측에 의거해 설계에 유연성을 부여하기 보단 단순성을 유연하게 적용한후 테스트를 철저하게 하는 것이 효과적이다.

단순성은 유연성을 촉진시킨다. 예를 들어 옵션을 제거하면 프로그램의 수정은 더욱 간단해진다.

커뮤니케이션을 중시하면 코드를 이해하기 쉬워지므로 수정이 쉬워진다. 이로써 유연성이 증대된다.

원칙 

각 패턴은 가치 중 하나 이상을 내표하고 있다.

원칙은 일반적인 생각을 담고 있으며, 패턴의 근간을 이룬다.

원칙을 명확하게 알고 있다면 새로운 패턴들을 만들어낼 수 있다.

또한 패턴을 사용하는 근본적인 이유를 알 수 있다.

지역적 변화

코드를 수정할 때 함께 바꿔야하는 부분을 최소화하라

지역적 변화만을 일으키는 코드는 커뮤니케이션이 쉽다.

최소 중복

중복된 코드가 많을 수록 코드의 수정이 어려워진다.

어떤 개념을 수정했을 때 클래스를 2개 이상 수정해야한다면, 이는 지역적 변화의 원칙을 위배한다.

하지만 코드의 중복은 상황에 따라 불가피할 수 있다.

따라서 절대적으로 피하기 보단 위험 요소로 보는 것이 좋다.

로직과 데이터의 결합

데이터와 그 데이터를 처리하는 로직을 같은 메소드 , 같은 객체 , 같은 패키지 내에 배치하라

이렇게 하면 프로그램을 수정하더라도 그 영향이 일정 영역에 머물게 된다.

대칭성

대칭성에 따라 아이디어를 일관된 방식으로 표현하자

메소드를 하나의 구현으로 통합할 수 있어서 중복을 제거할 수 있다.

void process() {
	input();
    	tally(); // 일치시키다
   	output();
}

선언적 표현

수행 순서가 중요한 구문이나 조건부 구문이 없는 경우, 선언적 표현을 통해 코드를 작성하는 것이 좋다.

(아마 어노테이션인 듯)

@RunWith(Suite.class)
@TestClasses({
	SimpleTest.class,
    ComplicatedTest.class
}
)
class AllTests {
}

이런 방식으로 내부를 볼 필요없이 읽기 쉬운 코드를 작성할 수 있다.

변화율

로직과 데이터를 함께 관리하고 변화율이 다른 로직과 데이터를 분리하라

변화율은 시간적 대칭성에 해당한다.

하나의 객체에 있는 모든 필드는 가급적 함께 변해야한다.

특정 메소드가 수행될 때만 사용되는 필드는 그 메소드의 지역 변수로 선언되어야한다.

예를 들어 함께 변화하는 두 개의 필드(value, currency)가 있다면 하나의 도우미 객체(Money)에 넣는 것이 좋다.

setAmount(Money value) {
	this.money = money;
}