기본 액세스는 개인용 액세스 수정자를 중복으로 렌더링하지 않습니다.
언어 디자이너의 입장은 공식 튜토리얼- 클래스 멤버에 대한 액세스 제어에 반영되며 매우 명확합니다 (편의를 위해 인용 부호로 굵게 표시 ).
액세스 레벨 선택에 대한 팁 :
다른 프로그래머가 클래스를 사용하는 경우 오용으로 인한 오류가 발생하지 않도록해야합니다. 액세스 수준이 도움이 될 수 있습니다.
- 특정 회원에게 적합한 가장 제한적인 액세스 수준을 사용하십시오. 합당한 이유가없는 한 비공개로 사용하십시오.
- 상수를 제외한 공용 필드는 피하십시오. (자습서의 많은 예제는 공개 필드를 사용합니다. 이는 간결하게 몇 가지 요점을 설명하는 데 도움이 될 수 있지만 프로덕션 코드에는 권장되지 않습니다.) 공개 필드는 특정 구현에 연결하고 코드 변경시 유연성을 제한하는 경향이 있습니다.
예를 들어 TDD에 대한 새로운 답변에서 알 수 있듯이 개인 수정자를 완전히 삭제한다는 정당화 로 인해 테스트 가능성에 대한 귀하의 호소 가 잘못되었습니다 . 지금 개인 메소드를 피해야합니까?
물론 개인 메소드를 가질 수 있으며 물론 테스트 할 수도 있습니다.
어느 쪽이 어떤 당신이 그런 식으로 그것을 테스트 할 수 있습니다, 또는이없는 경우에 실행에 민간 방법을 얻을 수있는 방법으로, 어떤 실행하는 개인 얻을 수있는 방법은, 경우에 왜 도대체 당신은 단지 그것을 테스트하기 위해 노력하고있다 빌어 먹을 물건을 삭제 ...
패키지 수준 액세스의 목적과 사용법에 대한 언어 디자이너의 입장은 다른 공식 자습서 인 패키지 만들기 및 사용에 설명되어 있으며 개인 수정자를 삭제한다는 아이디어와는 아무런 관련이 없습니다 (편의를 위해 굵은 글씨로 인용 ) :
다음을 포함하여 여러 가지 이유로 이러한 클래스와 인터페이스를 패키지로 묶어야합니다.
- 귀하와 다른 프로그래머는 이러한 유형이 관련이 있는지 쉽게 확인할 수 있습니다 ...
- 패키지 내의 유형이 서로 무제한으로 액세스하도록 허용하면서도 패키지 외부의 유형에 대한 액세스는 여전히 제한 할 수 있습니다 ...
<rant "충분한 소리가 들렸다 고 생각합니다. 크고 분명하게 말할 때가 왔다고 생각합니다 ...">
개인 방법은 단위 테스트에 유리합니다.
아래는 사용자가 코드 범위에 익숙하다고 가정합니다 . 그렇지 않다면 단위 테스트와 테스트에 관심이있는 사람들에게 매우 유용하기 때문에 배우는 데 시간이 걸립니다.
좋아, 그래서 그 개인 방법과 단위 테스트, 그리고 범위 분석이 있다는 커버리지 분석을 얻었고, 내 개인 방법은 테스트에 포함되지 않습니다. 지금...
비공개로 유지하면 무엇을 얻을 수 있습니까
메소드는 개인용이므로 진행하는 유일한 방법은 코드를 연구하여 비 개인용 API를 통해 사용되는 방법을 배우는 것입니다. 일반적으로 이러한 연구에 따르면 테스트에서 특정 사용 시나리오가 누락 된 것입니다.
void nonPrivateMethod(boolean condition) {
if (condition) {
privateMethod();
}
// other code...
}
// unit tests don't invoke nonPrivateMethod(true)
// => privateMethod isn't covered.
완전성을 위해, 그러한 커버리지 갭에 대한 다른 (덜 빈번한) 이유는 사양 / 디자인의 버그 일 수 있습니다. 나는 여기에 깊이 들어 가지 않고 단순하게 유지합니다. "방법을 테스트 할 수 있도록"액세스 제한을 약화 시키면 이러한 버그가 존재한다는 사실을 알 수 없을 것입니다.
문제를 해결하기 위해 누락 된 시나리오에 대한 단위 테스트를 추가하고 적용 범위 분석을 반복하며 차이가 사라 졌는지 확인합니다. 지금 무엇을해야합니까? 비공개 API의 특정 사용법에 대한 새로운 단위 테스트를 받았습니다.
새로운 테스트를 통해이 사용에 대한 예상 동작이 변경되지 않으면 테스트가 실패하므로 예고없이 변경되지 않도록합니다.
외부 독자는이 테스트를 살펴보고 어떻게 사용하고 행동 해야하는지 배울 수 있습니다 (여기서 외부 독자는 미래의 자기 자신을 포함합니다.
새로운 테스트는 리팩토링에 대한 허용 (이렇게 나는 당신이 내기!? 개인 방법을 리팩토링) I가 무엇을 할 것입니다 privateMethod, 난 항상 테스트 할 수 있습니다 nonPrivateMethod(true). 내가하는 일에 관계없이 privateMethod메소드가 직접 호출되지 않으므로 테스트를 수정할 필요가 없습니다.
나쁘지 않다? 당신은 내기.
액세스 제한을 약화시키는 것에서 무엇을 풀 수 있습니까?
이제 위 대신에 액세스 제한을 약화한다고 상상해보십시오. 메서드를 사용하는 코드 연구를 건너 뛰고 my를 호출하는 테스트를 계속 진행합니다 exPrivateMethod. 큰? 아니!
위에서 언급 한 비공개 API의 특정 사용에 대한 테스트를 받습니까? 아니요 : nonPrivateMethod(true)이전 에는 테스트 가 없었으며 지금은 그러한 테스트가 없습니다.
외부 독자가 수업 사용법을 더 잘 이해할 수있는 기회를 얻습니까? 아니요 ? "- 잊어 버려, 그것은 내부 사용을 엄격입니다 - -. 이봐 방법의 목적은 여기에 테스트거야. 아차"
리팩토링에 내성이 있습니까? 안 돼요 :에서 변경 exPrivateMethod하면 테스트를 중단 할 수 있습니다. 이름 바꾸기, 다른 방법으로 병합, 인수 변경 및 테스트는 컴파일을 중지합니다. 두통? 내기!
요약하면 개인 방법을 고수하면 단위 테스트에서 유용하고 안정적인 기능을 향상시킬 수 있습니다. 대조적으로, "테스트 가능성"에 대한 접근 제한의 약화는 나에게 모호하고 이해하기 어려운 테스트 코드를 제공 할 뿐이다. 솔직히 내가 얻는 것은 기술 부채 처럼 보입니다 .
</ rant>