Java에 '서브 클래스 전용'액세스 수정자가없는 이유는 무엇입니까?

Java에는 메소드에 사용할 수있는 네 가지 액세스 수정자가 있습니다.

public -모든 클래스에서이 방법을 사용할 수 있습니다.

protected -동일한 패키지의 클래스와 모든 패키지의 서브 클래스가이 메소드를 사용할 수 있습니다.

private -이 클래스 만이 메소드를 사용할 수 있습니다.

no modifier ( "package private")-동일한 패키지의 클래스 만이 메소드를 사용할 수 있습니다.

자주 일어나는 일은 모든 서브 클래스가 사용할 수있는 수퍼 클래스에 유용한 메소드를 원한다는 것입니다. 그러나 다른 클래스 가이 메소드에 액세스하는 것은 의미가 없으며 어떤 의미에서는 캡슐화를 깨뜨릴 수 있습니다.

따라서이 유용한 메소드를 수퍼 클래스 public또는 에서 선언해야합니다 protected.이 패키지는 적어도 패키지의 다른 모든 클래스에 노출됩니다. 서브 클래스에서만 사용하기위한 것이지만.

subclasses-onlyJava에 액세스 수정자가 없는 이유가 있습니까? 나에게는 매우 이상해 보인다. 뭔가 빠졌습니까?

또한 subclasses-only액세스 수정자는 변수를 서브 클래스에만 노출하려는 경우에도 유용합니다. 나에게 많은 일이 일어난다.

protected 수정자를 사용 하고 상위 클래스와 해당 서브 클래스 만 동일한 패키지에 있도록함으로써 서브 클래스 전용 수정자를 에뮬레이트 할 수 있기 때문 입니다.

패키지는 응집력 측면에서 큰 프로젝트를 구성하는 데 도움이 될뿐만 아니라 동일한 패키지의 클래스에 일부 수준의 커플 링이있을 수 있음을 보여주기 때문에 실제로 모범 사례입니다.

Java에는 원래 그러한 수정자가있었습니다. private protectedJava 1.0에서 작성 되었지만 제거되었습니다.

추가 복잡성은 비용이 들지 않는다는 판단이 필요하다고 생각합니다.

모든 언어 기능에는 비용이 있습니다 : 새로운 프로그래머에게 가르치기 위해; 문서에서; 컴파일러, JVM 및 개발 도구에서 구현할 때 프로그램 정확성에 대한 추론; 미래 언어 진화를 제한하는 것; 그리고 더. 언어 기능은 서로 상호 작용하며 잠재적으로 N ² 상호 작용 과 상호 작용합니다.

Java 프로그래머와 Java 스펙을 읽은 비율은 몇 퍼센트입니까? 나는 그것이 적은 비율이라고 확신합니다. 이것은 우리가 신뢰할 수있는 이해와 엔지니어링 제품을 위해 더 간단한 언어를 주장합니다.

private protected패키지가 모듈화의 주요 단위이기 때문에이 기능 의 이점 은 적습니다.

액세스 제어는 클래스 방법 및 특성에 대해 클래스와 함께 작업하는 가상 개발자의 커버리지의 결과로 생각할 수 있습니다 ...

당신 : 당신이 x를하고 싶다고 말하면, doX 메소드를 호출합니다. DEV : 더 말해주세요 .. 인수가 무엇입니까?

이것은 공개입니다 ...

당신 : doX 안에서 나는 전화를합니다. DEV : 너무 많은 정보, 저는 그것에 관심이 없습니다. 사용 방법을 알고 싶습니다. 다른 걸 말해줘

이것은 비공개입니다 ...

당신 : 서브 클래 싱 할 때 doX와 doY는 doIt을 호출합니다.

이것은 보호됩니다 ...

당신 : 나는 한 시간 안에 휴가를 떠날 예정입니다. 앞으로 6 개월 동안 갈 것입니다. 보스는이 강아지가 당신의 것이라고 말합니다! 안녕. DEV : 기다리지 말고 다 말해줘 ...

패키지입니다.

YOU : doItWhen 메소드는이 클래스에서만 호출되며 10 년 동안 변경되지 않았습니다. 그것은 ... DEV : 우와, 우리는 50 분까지입니다. 다음 속성으로 더 빨리 이야기하십시오.

이것은 비공개로 보호됩니다 ...

이것은 이미 존재합니다. 보호되어 있습니다.

패키지 내에 존재하는 클래스를 제어 할 수 있습니다. 패키지에 다른 클래스가없고 주어진 변수 또는 메소드가 보호 된 경우 '하위 클래스 만'입니다.

즉, 패키지 내에 어떤 클래스가 있는지 제어 할 수 있습니다. 보호 된 메소드 또는 변수 만 사용하도록 선택할 수 있습니다.