클래스 디자인 기법

1. 데이터 의 개인 정 보 를 반드시 확보 해 야 한다.
이것 이 가장 중요 하 다.절대 포장 성 을 파괴 하지 마 세 요.때로는 접근 기 방법 이나 변경 기 방법 을 만들어 야 하지만 인 스 턴 스 필드 의 개인 성 을 유지 하 는 것 이 좋 습 니 다.많은 뼈 아 픈 경험 은 데이터 의 표현 형식 이 바 뀔 수 있 지만 그들의 사용 방식 은 자주 변 하지 않 는 다 는 것 을 알려 준다.데이터 가 개인 적 으로 유 지 될 때 그들의 표현 형식의 변 화 는 유형의 사용자 에 게 영향 을 주지 않 고 bug 가 나타 나 도 쉽게 검 측 할 수 있다.
2. 데이터 초기 화
자바 는 부분 변 수 를 초기 화하 지 않 지만 대상 의 인 스 턴 스 도 메 인 을 초기 화 합 니 다.시스템 의 기본 값 에 의존 하지 않 고 모든 데 이 터 를 명시 적 으로 초기 화 하 는 것 이 좋 습 니 다. 구체 적 인 초기 화 방식 은 기본 값 을 제공 할 수도 있 고 모든 구조 기 에서 기본 값 을 설정 할 수도 있 습 니 다.
3. 클래스 에 너무 많은 기본 유형 을 사용 하지 마 세 요.
여러 관련 기본 유형의 사용 을 다른 종류 로 대체 한 다 는 것 이다.이렇게 하면 종 류 를 더욱 이해 하기 쉽 고 수정 하기 쉽다.예 를 들 어 Address 라 고 불 리 는 새로운 클래스 로 Customer 클래스 중 다음 과 같은 인 스 턴 스 필드 를 교체 합 니 다.

private String street;
private String city;
private String state;
private int zip;

이렇게 하면 주소 의 변 화 를 쉽게 처리 할 수 있다. 예 를 들 어 국제 주소 에 대한 처 리 를 늘 려 야 한다.
4. 모든 도 메 인 에 독립 된 도 메 인 접근 기와 도 메 인 변경 기 가 필요 한 것 은 아 닙 니 다.
직원 들 의 급 여 를 받 거나 설정 해 야 할 지도 모른다.직원 대상 을 구성 하면 고용 날 짜 를 변경 하 는 것 을 금지 하고 대상 에는 다른 사람 이 받 거나 설정 하 기 를 원 하지 않 는 인 스 턴 스 필드 가 자주 포함 되 어 있다. 예 를 들 어 address 류 에 주 줄 임 말 을 저장 하 는 배열 이다.
5. 직책 이 너무 많은 유형 을 분해한다.
이렇게 말 하 는 것 은 좀 모호 한 것 같은 데, 도대체 얼마 가 '과 다' 라 고 할 수 있 습 니까?사람마다 견해 가 다르다.그러나 복잡 한 종 류 를 두 가지 더 간단 한 종류 로 뚜렷하게 분해 할 수 있다 면 그것 을 분해 해 야 한다 (그러나 다른 한편 으로 는 극단 을 걷 지 마라. 10 가지 종 류 를 설계 하 는데 각 종 류 는 한 가지 방법 만 있 을 뿐 분명히 너무 잘못 되 었 다).다음은 부정적인 디자인 예시 이다.

public class CardDeck // bad design
{
private int  value;
private int[] suit;
public CardDeck() { . . . }
public void shuffle0 { • • • }
public int getTopValueO { . . . }
public int getTopSuitO { . . . }
public void drawO {• ■ . }
}

실제로 이 종 류 는 두 가지 독립 적 인 개념 을 실현 했다. 한 장의 카드 (shuffle 방법 과 draw 방법 포함) 와 한 장의 카드 (액면가 와 무늬 를 보 는 방법 포함). 또한 한 장의 카드 를 나타 내 는 카드 류 를 도입 했다. 현재 두 가지 유형 이 있 는데 각 유형 은 자신의 직책 을 완성 한다.

public cl ass CardDeck
{
private Card[] cards;
public CardDeckO { • . . }
public void shuffle() { . . . }
public Card getTopO { . . . }
public void draw() { . . . }
}
public class Card
{
private int value;
private int suit;
146 Java    ?
public Card(int aValue, int aSuit) { . . . }
public int getValueO { . . . }
public int getSuitO { . . . }
}

6. 유형 명 과 방법 명 은 그들의 직책 을 나 타 낼 수 있어 야 한다.
변 수 는 그 의 미 를 반영 할 수 있 는 이름 이 있어 야 하 는 것 과 마찬가지 로 클래스 도 그래 야 한다.) 또는 동사 ("- ing" 접미사 가 있 음) 수식 명사 (예 를 들 어 Date. 방법 에 있어 서 습관 은 방문 기 방법 은 소문 자 get 으로 시작 하 는 것 Order 이 고, 변경 기 방법 은 소문 자 set 로 시작 하 는 것 RushOrder 이다.
7. 가 변 적 이지 않 은 종 류 를 우선 사용BillingAddress 류 및 getSalary 가방 의 다른 종 류 는 가 변 적 이지 않 습 니 다. 대상 의 상 태 를 수정 할 방법 이 없습니다. 유사 setSalary변 경 된 대상 이 아니 라 변 경 된 상 태 를 되 돌려 주 는 방법 입 니 다. 변 경 된 대상 의 문 제 는 여러 스 레 드 가 한 대상 을 동시에 업데이트 하려 고 하면 동시에 변 경 됩 니 다. 그 결 과 는 예측 할 수 없습니다. 클래스 가 변 하지 않 으 면 여러 스 레 드 에서 대상 을 안전하게 공유 할 수 있 습 니 다. 따라서 가능 한 한 클래스 가 변 하지 않도록 해 야 합 니 다.이것 은 아주 좋 은 생각 입 니 다. 값 을 표시 하 는 클래스, 예 를 들 어 문자열 이나 시간 대 등 은 특히 쉽 습 니 다. 계산 은 원래 의 값 을 업데이트 하 는 것 이 아니 라 새로운 값 을 생 성 합 니 다. 물론 모든 클래스 가 변 하지 않 아야 하 는 것 은 아 닙 니 다. 직원 들 이 임금 을 올 릴 때 LocalDate 방법 을 새로운 java.time 대상 으로 되 돌려 주 는 것 은 이상 합 니 다.
출처: Core Java Volume I – Fundamentals, 10th Edition