1. 소개
변수가 선언될 때 또는 생성자에서 초기화할지 여부에 대해 Java 개발자 간에 불확실성이 있습니다.
이 사용방법(예제)에서는 선언 또는 생성자에서 변수를 초기화할 때 어떤 일이 발생하는지 살펴보겠습니다 . 존재하는 경우 차이점과 유사점을 지적하려고 노력할 것입니다.
2. 필드 선언 초기화
우리는 Java 컴파일러가 모든 필드 선언 초기화를 제거 하고 클래스에 나타나는 순서대로 생성자에서 코드로 이동 한다는 것을 알아야 합니다 . 이것으로부터 우리는 선언에서 변수를 초기화하는 것과 생성자에서 변수를 초기화하는 것 사이에 큰 차이가 없다고 추론할 수 있습니다 . 왜냐하면 컴파일 후에 어쨌든 생성자에서 끝나기 때문입니다.
public class A {
private B b = new B();
}3. 생성자 필드 초기화
위의 코드에서 컴파일 후 다음 생성자로 끝납니다.
public class A {
private B b;
public A() {
this.b = new B();
}
}그렇다면 어디에서 데이터를 초기화하느냐가 중요할까요?
컴파일 후 무슨 일이 일어나는지 알고 나면 그다지 많지 않습니다. 우리가 경험을 바탕으로 형성하는 경향이 있는 선호도에 가깝습니다.
4. 지침
필드 선언 또는 생성자에서 데이터를 초기화할지 여부를 결정할 때 몇 가지 지침을 살펴볼 수 있습니다 .
이것은 의존성 주입 생성자입니다.
public A(B b) {
this.b = b;
}변수를 초기화하는 권장 방법은 의존성 주입을 사용하는 것 입니다. 객체를 초기화하는 이 방법을 사용함으로써 우리는 다른 원칙을 고수합니다.
4.1. 가독성
가독성을 높이 려면 필드 선언 또는 생성자에서 데이터를 초기화하는 것이 중요 할 수 있습니다 . 물론 둘 다 가질 수 있기 때문에 우리는 이것을 규칙이 아니라 지침으로 받아들여야 합니다.
한 곳에서 모든 초기화를 수행하면 초기화 코드를 찾을 위치를 쉽게 알 수 있습니다. 이렇게 하면 미래의 개발자가 여러 곳에 흩어져 있지 않고 한 곳에서만 초기화를 더 쉽게 볼 수 있습니다.
4.2. 단일 책임
의존성 주입 생성자를 사용하여 A 클래스 에서 B 개체를 인스턴스화하는 책임을 제거합니다. 가능 하면 단일 책임 원칙을 따르는 것이 항상 바람직합니다.
이것은 또한 우리가 따라야 할 또 다른 멋진 지침인 클래스 간의 결합 이 낮아질 것임을 의미 합니다.
4.3. 테스트 가능성
이 생성자를 사용하면 B 개체를 쉽게 모의 처리한 다음 이 생성자를 사용하여 A 개체에 주입 할 수 있으므로 코드를 테스트하는 것이 더 쉽습니다 .
B b = mock(B.class);
A a = new A(b);4.4. 유지 보수성
결합 클래스가 낮으면 코드 유지 관리도 더 좋아 집니다. 따라서 코드를 더 쉽게 수정할 수 있습니다.
5. 결론
이 기사에서 우리는 필드 선언 또는 생성자 초기화를 사용 하는 것이 기본 설정 에 가깝고 이들 사이의 몇 가지 차이점이 우리가 따르고자 하는 디자인 원칙이 될 수 있음을 확인했습니다.
생성자 초기화와 의존성 주입을 사용하면 설계 원칙의 몇 가지 이점을 얻을 수 있습니다 .
항상 그렇듯이 예제의 소스 코드는 GitHub에서 사용할 수 있습니다 .
