켄트백의 구현패턴 6장 - 상태

 

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

상태

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

 

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

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)

 

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