Tech Log 🛠️

클래스

내부 클래스

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

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

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

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;
}