| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
Tags
- JPA
- javascript
- Spring Boot
- 독후감
- 맛집
- jface
- Git
- 스프링
- 후기
- nodejs
- 인터페이스
- java
- boot
- 엘라스틱서치
- effective
- java8
- MySQL
- elasticsearch
- 백준
- 이펙티브
- RCP
- 알고리즘
- node
- 자바스크립트
- 자바
- Web
- error
- 리뷰
- Spring
- kibana
Archives
- Today
- Total
wedul
클래스와 인터페이스 - 규칙 14 public 클래스 안에는 public 필드를 두지 말고 접근자 메서드를 사용하라 본문
JAVA/Effective Java
클래스와 인터페이스 - 규칙 14 public 클래스 안에는 public 필드를 두지 말고 접근자 메서드를 사용하라
wedul 2018. 5. 29. 22:29반응형
가끔 아래 기재된 클래스 처럼 클래스 내부에서 사용할 데이터를 처리하기 위해
임시 클래스를 만드는 경우가 있다.
1 2 3 4 | class Temp { private String t; private String f; } | cs |
이런 경우에는 이 클래스를 직접 조작할 수 있기 때문에 캡슐화의 이점이 사라질 수 밖에 없다.
하지만 package-private 클래스나 private 중첩 클래스는 데이터의 필드가 공개되더라도 잘못이라 말할 수 없다.
대신 클래스가 추상화 하려는 내용을 제대로 기술하기만 하면 된다.
기존의
public 클래스가 내부 필드를 외부로 공개하는 것은 바람직하지 않지만, 변경 불가능 필드는 그 심각성이 덜하다.
다음과 같이 내부 변수를 public으로 공개하여도 어떤한 동작도 하지 못하게(immutable)하게 설계가 되어 있는 경우에는 문제가 되지 않는다.
1 2 3 4 | public final class Time { public final int hour; public final int minute; } | cs |
두서가 길었지만, 정리하자면
- public 클래스에서 변경이 가능한 필드는 외부에 공개되어서는 안된다.
- package-private나 private로 선언된 중첩 클래스의 필드는 그 변경 가능 여부와 상관없이 외부로 공개 되어도 크게 문제가 되지 않는 경우가 있다.
출처 : 조슈아 블로크, 『 Effective Java 2/E』, 이병준 옮김, 인사이트(2014.9.1), 규칙14 인용.
반응형
'JAVA > Effective Java' 카테고리의 다른 글
| 클래스와 인터페이스 - 규칙 16 계승하는 대신 구성하라. (0) | 2018.05.29 |
|---|---|
| 클래스와 인터페이스 - 규칙 15 변경 가능성을 최소화하라 (0) | 2018.05.29 |
| 클래스와 인터페이스 - 규칙 13 클래스와 멤버의 접근권한은 최소화하라. (0) | 2018.05.29 |
| 모든 객체의 공통 메서드 - 규칙 12 Comparable 구현을 고려하라. (0) | 2018.05.29 |
| 모든 객체의 공통 메서드 - 규칙 11 clone을 재정의할 때는 신중하라 (0) | 2018.05.29 |
