init () 메소드는 코드 냄새가 있습니까?

init()유형에 대한 메소드를 선언 할 목적이 있습니까?

나는 우리가 생성자를 선호init() 해야하는지 또는 선언을 피하는 방법을init() 묻지 않습니다 .

이 경우 내가 부탁 해요 어떤 선언 뒤에 이론적 init()방법 (그것이 얼마나 일반적인보고를) 또는 코드 냄새의 경우 피해야한다.

init()관용구는 매우 일반적이지만, 나는 실제 혜택을 볼 아직.

메소드를 통한 초기화를 장려하는 유형에 대해 이야기하고 있습니다.

class Demo {
    public void init() {
        //...
    }
}

프로덕션 코드에서 언제 사용됩니까?

생성자가 객체를 완전히 초기화하지 않아 부분적으로 생성 된 객체가 생성되기 때문에 코드 냄새가 날 수 있다고 생각합니다. 상태가 설정되지 않은 경우 개체가 존재하지 않아야합니다.

이것은 엔터프라이즈 응용 프로그램의 의미에서 생산 속도를 높이는 데 사용되는 일종의 기술의 일부라고 생각합니다. 그런 관용구가 있다고 생각할 수있는 유일한 논리적 인 이유입니다. 그렇다면 어떻게 유익한 지 잘 모르겠습니다.

예, 코드 냄새입니다. 코드 냄새는 반드시 제거해야하는 것은 아닙니다. 다시 한 번 살펴 보는 것입니다.

여기에는 기본적으로 다른 두 가지 상태 인 사전 초기화 및 사후 초기화라는 객체가 있습니다. 그러한 국가들은 서로 다른 책임, 부름을받을 수있는 다른 방법 및 행동이 다릅니다. 효과적으로 두 개의 다른 클래스입니다.

물리적으로 두 개의 개별 클래스를 만들면 잠재적 인 버그의 전체 클래스를 정적으로 제거 할 수 있습니다. 대신 모델이 "실제 모델"과 거의 일치하지 않을 수 있습니다. 당신은 일반적으로 첫 번째 이름 Config또는 Setup그런이나 뭐.

다음에, construct-init 이디엄을 2 클래스 모델로 리팩토링하고 그것이 어떻게 당신에게 적합한 지보십시오.

때에 따라 다르지.

init방법은 생성자로부터 분리 된 객체의 초기화가 필요없는 경우 코드 냄새이다. 이러한 단계를 분리하는 것이 적절한 경우가 있습니다.

빠른 Google 검색 으로이 예를 얻었습니다 . 객체 할당 (생성자) 중에 실행 된 코드가 초기화 자체와 더 잘 분리 될 수있는 더 많은 경우를 쉽게 상상할 수 있습니다. 레벨 시스템이 있고 할당 / 구성은 레벨 X에서 발생하지만 레벨 Y에서만 초기화가 발생합니다. Y 만 필요한 매개 변수를 제공 할 수 있기 때문입니다. "init"는 비용이 많이 들고 할당 된 오브젝트의 서브 세트에 대해서만 실행되어야하며 해당 서브 세트의 결정은 레벨 Y에서만 수행 할 수 있습니다. 생성자로 수행 할 수없는 클래스. 레벨 X는 상속 트리에서 할당 된 객체를 제공하지만 레벨 Y는 구체적인 인터페이스 (어디에서나init 아마도 정의).

물론 내 경험에 따르면이 사례는 생성자에서 직접 모든 초기화를 수행 할 수있는 표준 사례의 일부에 불과하며 별도의 init방법 을 볼 때마다 필요성에 대해 의문을 제기하는 것이 좋습니다.

내 경험은 두 그룹으로 나뉩니다.

1. 실제로 init ()가 필요한 코드. 수퍼 클래스 또는 프레임 워크가 클래스 생성자가 생성 중에 모든 종속성을 얻지 못하는 경우에 발생할 수 있습니다.
2. init ()가 사용되었지만 피할 수있는 코드.

내 개인적인 경험에서 나는 단지 (1)의 몇 가지 사례를 보았지만 (2)의 더 많은 사례를 보았습니다. 결과적으로, 나는 보통 init ()가 코드 냄새라고 가정하지만 항상 그런 것은 아닙니다. 때때로 당신은 단지 주위를 돌아 다닐 수 없습니다.

빌더 패턴을 사용하면 init ()가 필요 / 욕망을 제거하는 데 도움이 될 수 있습니다.

Init 메소드가 유용한 일반적인 시나리오는 변경하려는 구성 파일이 있고 응용 프로그램을 다시 시작하지 않고 변경 사항을 적용하는 경우입니다. 물론 이것은 Init 메소드가 생성자와 별도로 호출되어야한다는 것을 의미하지는 않습니다. 생성자에서 Init 메소드를 호출 한 다음 구성 매개 변수가 변경 될 때 나중에 호출 할 수 있습니다.

요약하면 : 코드 냄새인지 여부에 관계없이 대부분의 딜레마는 상황과 상황에 따라 다릅니다.

사용 방법에 따라 다릅니다.

비디오 게임을 만들고 성능을 유지해야 할 때와 같이 가비지 수집기의 성능을 저하시킬 때와 같이 힙에 객체를 계속 할당하지 않으려는 경우 Java / C #과 같은 가비지 수집 언어에서 해당 패턴을 사용합니다. 생성자를 사용하여 필요한 다른 힙 할당 init을 만들고 재사용 할 때마다 기본 유용한 상태를 만듭니다. 이것은 객체 풀의 개념과 관련이 있습니다.

초기화 명령의 공통 서브 세트를 공유하는 여러 생성자가있는 경우에도 유용하지만이 경우 init개인용입니다. 그렇게하면 가능한 한 각 생성자를 최소화 할 수 있으므로 각 생성자는 고유 한 지침과 init나머지 작업을 수행 하는 단일 호출 만 포함합니다 .

그러나 일반적으로 코드 냄새입니다.

init()메소드는 다른 오브젝트가 동시에 사용하는 외부 자원이 필요한 오브젝트 (예 : 네트워크 연결)가있는 경우 상당히 의미가 있습니다. 객체 수명 기간 동안 리소스를 사용하지 않으려는 경우가 있습니다. 이러한 상황에서는 자원 할당이 실패 할 때 생성자에서 자원을 할당하지 않을 수 있습니다.

특히 임베디드 프로그래밍에서는 결정적인 메모리 풋 프린트를 원하므로 생성자를 조기에 호출하거나 정적 일 수도 있고 특정 조건이 충족되는 경우에만 초기화하는 것이 일반적입니다.

그러한 경우를 제외하고는 모든 것이 생성자로 들어가야한다고 생각합니다.

일반적으로 기능적 인스턴스에 필요한 모든 인수를받는 생성자를 선호합니다. 그것은 그 객체의 모든 의존성을 분명히합니다.

반면에 매개 변수가없는 공용 생성자가 필요한 간단한 구성 프레임 워크와 종속성 및 구성 값을 주입하기위한 인터페이스를 사용합니다. 그 후에 구성 프레임 워크 init는 객체 의 메소드를 호출 합니다. 이제 내가 가진 모든 것을 받았으며 작업 준비를 위해 마지막 단계를 수행하십시오. 그러나 참고 : 그것은 자동으로 init 메소드를 호출하는 구성 프레임 워크이므로 호출하는 것을 잊지 마십시오.

init () 메서드가 의미 적으로 객체의 상태 수명주기에 포함 된 경우 코드 냄새가 없습니다.

객체를 일관된 상태로 만들기 위해 init ()를 호출해야하는 경우 코드 냄새입니다.

이러한 구조가 존재하는 몇 가지 기술적 이유가 있습니다.

1. 프레임 워크 훅
2. 객체를 초기 상태로 재설정 (중복 방지)
3. 테스트 중 무시 가능성

init 이름은 때때로 불투명 할 수 있습니다. 자동차와 엔진을 봅시다. 자동차를 시동하려면 (전원 만 켜고 라디오를 들으려면) 모든 시스템이 준비되었는지 확인하십시오.

따라서 엔진, 문, 바퀴 등을 구성하면 화면에 엔진 = 꺼짐이 표시됩니다.

엔진 등은 모두 비싸므로 모니터링을 시작할 필요가 없습니다. 그런 다음 키를 돌리면 엔진-> 시동이라고합니다. 모든 고가의 프로세스를 실행하기 시작합니다.

이제 엔진 =이 보입니다. 그리고 점화 과정이 시작됩니다.

엔진을 사용할 수 없으면 자동차가 켜지지 않습니다.

복잡한 계산으로 엔진을 대체 할 수 있습니다. 엑셀 셀처럼. 모든 셀이 항상 모든 이벤트 핸들러로 활성화 될 필요는 없습니다. 셀에 집중하면 시작할 수 있습니다. 그런 식으로 성능을 향상시킵니다.