Java 보호 필드와 공용 게터

Java 보호 필드와 공용 게터

---

더 나은 방법과 이유 : 보호 된 필드 또는 private 필드의 공용 getter를 통해 기본 클래스 변수에 액세스합니다.

(게터는 관계없이 공개됩니다)

---

어쨌든 퍼블릭 게터가 있다면 왜 절대적으로 필요한 것보다 더 넓게 필드 자체를 노출하고 싶습니까? 즉, 하위 클래스에서 즉시 쓸 수 있음을 의미합니다 (최종 시작하지 않는 한).

개인적으로 필자는 모든 필드를 비공개로 설정하는 것을 좋아합니다. API와 구현 사이의 명확한 분리를 제공합니다. 나는 수퍼 클래스와 서브 클래스 사이의 관계를 호출자와 피 호출자의 관계와 비슷하다고 생각합니다. 기본 구현에 대한 변경은 호출자를 중단해야하는 것보다 더 이상 서브 클래스를 중단해서는 안됩니다. 필드 이름은 다른 클래스에 영향을주지 않는 구현 세부 사항입니다.

내 견해는 때때로 다소 극단적 인 것으로 보인다 ...

---

항상 클래스의 공용 API에 대해 프로그래밍해야합니다. 즉, 공용 메서드를 사용해야합니다.

그 이유는 간단합니다. 언젠가 귀하 또는 다른 누군가가 구현을 변경하고 싶을 수 있습니다. 이것은 항상 가능해야합니다. 인스턴스 변수에 의존하는 경우 자신을 제한합니다.

또한 변수에 액세스 할 때 해당 변수가 읽기 전용인지 여부를 제어 할 수 없으며이 변수가 변경 될 때 검사를 추가 할 수 없습니다.

setter / getter를 사용하면 나중에 유효성 검사, 검사 등을 추가 할 수 있습니다. 변수를 읽기 전용으로 만들기 위해 getter 만 제공 할 수도 있습니다.

---

직접 현장 액세스는 선호되지 않습니다. 사용 public또는 protected세터 및 게터.

getter는 필요하지 않습니다. public"외부인"으로부터 데이터를 숨기고 싶지만 하위 클래스에 데이터를 제공하려면 다음을 사용하십시오.protected

---

필드 액세스 제어에 대한 Sun의 권장 사항 중 일부는 여기에 있습니다. 필드를 보호하면 하위 클래스뿐 아니라 패키지에도 노출됩니다. 일반적으로 위의 링크에서 언급했듯이 필드는 그렇게하지 않을 타당한 이유가없는 한 비공개 여야합니다.

---

효과적인 Java 2nd Edition은 말합니다.

항목 13 : 클래스 및 멤버의 접근성 최소화

경험의 법칙은 간단합니다. 각 클래스 또는 멤버를 가능한 한 액세스 할 수 없도록 만드십시오. 즉, 작성중인 소프트웨어의 적절한 기능과 일치하는 가능한 가장 낮은 액세스 수준을 사용하십시오.

따라서 보호 된 클래스 멤버가 필요한 이유가 확실하지 않은 경우 (즉, 동일한 패키지의 하위 클래스 또는 클래스에 액세스 할 수있는 필드가 필요하지 않음) private으로 선언하십시오. 클래스 외부에서 설정하려면 공용 setter를 만드십시오.

그러나 귀하의 회원이 최종 회원 인 경우 경우에 따라 보호하는 것이 괜찮을 수 있습니다 (즉, 민감한 정보를 공개하지 않음).

제가 언급하고 싶은 잠재적 보안 문제 중 하나는 배열이 보호 된 최종 (공개 최종 일지라도)으로 선언 된 경우 배열 참조가 최종 (수정할 수 없음)이지만 배열에 보유 된 객체는 최종이 아닙니다 (침입자가 배열 내용 변경).

---

C ++을 알고 있다면 아마 알고있을 것입니다.

const int * someMember

~와 다르다

int * const someMember

후자는 자바의 최종 배열과 같습니다.

---

앞서 언급 한 보안 허점에 대한 해결 방법은 배열의 전체 복사본을 반환하거나 읽기 전용 목록으로 반환하는 것입니다.

---

일반적으로 Sun의 권장 사항을 사용해야합니다. 한 가지 큰 예외가 있습니다. Android 용으로 프로그래밍하는 경우입니다.

그 이유는 성능 때문입니다. 모든 가상 메서드 호출에는 메서드를 개체로 라우팅하기 위해 조회 테이블을 사용하는 것과 관련된 오버 헤드가 있습니다. 이 오버 헤드는 지역 변수에 액세스 할 때 관련되지 않습니다.

다음은 이에 대해 좀 더 자세히 설명하는 링크입니다.

http://developer.android.com/training/articles/perf-tips.html#GettersSetters

http://blog.leocad.io/why-you-shouldnt-use-getters-and-setters-on-android/

달성하려는 작업을 아는 것이 중요합니다.

1. 필드 값은 공용 인터페이스를 사용하여 클라이언트 코드에 액세스 할 수 있어야합니다.
2. 이 필드는 서브 클래스에서 사용하기위한 것입니다.

평범한 자바에서 getter와 setter는 두 작업을 모두 수행합니다. 하지만 안드로이드는 다릅니다. # 1을 수행하는 경우 공용 getter 및 setter를 사용해야합니다. # 2를 수행하는 경우 보호 된 필드를 사용해야합니다. 둘 다 수행하는 경우 둘 다 사용하십시오.

---

Java의 "보호 된"필드를 보호하는 몇 가지 주장을 제시하고 싶습니다. "값 유효성 검사를 피해야하는 상황에서 공용 접근 자보다 보호 된 필드를 사용하여 기본 클래스 멤버에 액세스하는 것이 좋습니다". 그러나 그렇지 않은 경우 공개 접근자가있는 개인 필드를 사용하여 기밀 화를 보완해야합니다.

getter 및 setter의 원칙은 클래스 멤버에 입력 및 출력 된 값에 대한 유효성 검사를 제공하는 것입니다. 그러나 OOP 언어에서는 클래스가 아닌 객체에서 작동합니다. 기본 클래스와 특수 클래스는 단일 개체를 나타내므로 보호 된 필드를 통해 특정 클래스 멤버에 액세스하는 것이 완벽하게 괜찮습니다.

자동차에 대한 다음 추상 예제를 고려하십시오.-기본 클래스 Car 및 파생 클래스 Porshe가 있습니다. - 자동차 클래스는 같은 필드가있을 수 엔진 (아마도 엔진의 유형 만 개체 초기화 후 알려진) 자동차 생성자에서 설정되지 않은 값을 - 당신은 만들 Porshe의 계산에 사용되는 몇 가지 논리가 포함되어 클래스 객체 엔진 일부 외부 데이터를 사용하여 유형을 .

In this example, it is expected that engine field has a public getter, so car users know what engine the car has. However, there is no public setter as we expect car drivers not to temper with the engine! That is why, it is perfectly fine to make engine a protected field, so the Porshe class can set its value at some time in future.

Yes, some people will probably say "then use protected setter!". And I will repeat: in OOP languages we work with objects not classes. Single responsibility principle - yes, but as object not as class. If you say: "at some point if we use protected fields over 3 or 5 inheritance levels, it may be troublesome to understand what happens to the field if each class performs some operation with it". And then I answer: That is another antipattern - your object is probably too big at this point and voids Single Responsibility principle.

---

Accessing protected fields from a subclass is one of the ways that inheritance violates encapsulation. Using the public API is better for this reason.

참고URL : https://stackoverflow.com/questions/2279662/java-protected-fields-vs-public-getters