[oop] 비공개 대 보호됨-가시성 실용성 문제 [닫기]

여기서는 주로 메소드 액세스에 대해 이야기하고 있으며 클래스 가 멤버 액세스가 아닌 최종 클래스로 표시되는 정도는 조금 적습니다 .

오래된 지혜

“좋은 이유가없는 한 비공개로 표시하십시오.”

오픈 소스가 개발자 라이브러리 공간과 VCS / 종속성 관리 시스템을 지배하기 전까지는 며칠 만에 이해가되었습니다. Github, Maven 등 덕분에 하이퍼 콜라보레이션이되었습니다. 그 당시에는 라이브러리를 활용할 수있는 방법을 제한하여 돈을 벌었습니다. 나는 아마도이 “모범 사례”를 엄격히 고수하면서 경력의 처음 8 년 또는 9 년을 보냈다.

오늘 나는 그것이 나쁜 조언이라고 믿습니다. 때로는 메소드를 private 또는 class final로 표시하는 데 합리적인 주장이 있지만, 매우 드물고 심지어 개선되지 않는 경우가 있습니다.

넌 해본 적 있니:

• 상속 및 몇 줄의 코드로 해결할 수있는 버그가있는 라이브러리 등에 실망하거나 놀랐거나 상처를 받았지만 비공개 / 최종 방법과 클래스로 인해 절대로 올 수없는 공식 패치를 기다려야합니까? 나는 가지고있다.
• 저자가 상상 한 것과 약간 다른 유스 케이스에 라이브러리를 사용하고 싶었지만 개인 / 최종 방법 및 클래스로 인해 라이브러리를 사용할 수 없었습니까? 나는 가지고있다.
• 확장성에 과도하게 허용되는 라이브러리 등으로 인해 실망하거나 놀랐거나 다쳤습니까? 나는하지 않았다.

다음은 기본적으로 비공개 메소드 표시에 대해 들어 본 3 가지 합리화입니다.

합리화 # 1 : 안전하지 않으며 특정 방법을 무시할 이유가 없습니다.

필자가 작성한 특정 방법을 재정의해야하는지 여부에 대해 내가 틀린 횟수를 셀 수 없습니다. 몇 가지 인기있는 오픈 소스 라이브러리에서 작업 한 후, 사물을 표시하는 실제 비용을 어려운 방법으로 배웠습니다. 예상치 못한 문제 나 사용 사례에 대한 실질적인 해결책을 종종 제거합니다. 반대로, 나는 결코 16 년 이상 전문 개발에 API 안전과 관련된 이유로 개인이 아닌 보호 된 방법을 표시하는 것을 후회 . 개발자가 클래스를 확장하고 메서드를 재정의하기로 선택하면 의식적으로 “내가하는 일을 알고 있습니다”라고 말합니다. 생산성을 위해 충분해야합니다. 기간. 위험한 경우, 클래스 / 메소드 Javadocs에서주의하십시오. 맹목적으로 문을 닫지 마십시오.

기본적으로 보호되는 마킹 방법은 현대 SW 개발의 주요 문제 중 하나 인 상상력 상실의 완화입니다.

합리화 # 2 : 공용 API / Javadoc을 깨끗하게 유지

이것은 더 합리적이며 대상 고객에 따라 올바른 일이 될 수도 있지만 API를 “깨끗하게”유지하는 비용이 실제로 무엇인지 고려할 가치가 있습니다. 위에서 언급 한 이유로, 경우에 따라 기본적으로 보호되는 항목을 표시하는 것이 더 합리적입니다.

합리화 # 3 : 내 소프트웨어는 상용이므로 사용을 제한해야합니다.

이것은 합리적이지만 소비자는 매번 품질에 차이가 거의 없다고 가정하면서 덜 제한적인 경쟁자와 함께 갈 것입니다.

절대 말하지 마

나는 결코 메소드를 비공개로 표시하지 않는다고 말하고 있지 않다. 더 나은 경험 법칙은 “좋은 이유가 없다면 방법을 보호하는 것”입니다.

이 조언은 모듈로 나뉘어 진 라이브러리 또는 대규모 프로젝트에서 작업하는 사람들에게 가장 적합합니다. 더 작거나 더 많은 모 놀리 식 프로젝트의 경우 어쨌든 모든 코드를 제어하기 때문에 그다지 중요하지 않으며 필요할 때 / 필요할 때 코드의 액세스 수준을 쉽게 변경할 수 있습니다. 그럼에도 불구하고, 나는 여전히 똑같은 조언을 줄 것입니다 🙂

답변

class Car {
    private screw;
    public assembleCar() {
       screw.install();
    };
    private putScrewsTogether() {
       ...
    };
}