1. 클래스명의 첫 글자는 대문자로 표기한다. 필드, 메소드, 객체(핸들)의 첫 글자는 소문자여야 합니다. 모든 식별자와 마찬가지로, 그 안에 포함된 모든 단어는 서로 가까워야 하며, 중간에 있는 단어의 첫 글자는 대문자로 표시되어야 합니다. 예를 들어:
다음과 같이 코드를 복사합니다. ThisIsAClassName
thisIsMethodOrFieldName
상수 초기화 문자가 정의에 나타나는 경우 정적 최종 기본 유형 식별자의 모든 문자를 대문자로 표시합니다. 그러면 컴파일 타임 상수로 표시됩니다.
Java 패키지는 특별한 경우입니다. 중간 단어라도 모두 소문자입니다. com, org, net 또는 edu 등과 같은 도메인 이름 확장자 이름의 경우 모두 소문자여야 합니다. 이는 Java 1.1과 Java 1.2의 차이점 중 하나이기도 합니다.
2. 일반적인 용도로 클래스를 생성할 때 "클래식 형식"을 채택하고 다음 요소에 대한 정의를 포함하십시오.
다음과 같이 코드 코드를 복사합니다.
같음()
해시코드()
toString()
clone()(복제 가능 구현)
직렬화 가능 구현
3. 생성하는 각 클래스에 대해 해당 클래스를 테스트하기 위한 코드가 포함된 main() 배치를 고려하십시오. 프로젝트의 클래스를 사용하기 위해 테스트 코드를 삭제할 필요는 없습니다. 어떤 종류의 변경이 이루어지면 쉽게 테스트로 돌아갈 수 있습니다. 이 코드는 클래스 사용 방법의 예이기도 합니다.
4. 메소드는 불연속 클래스 인터페이스 부분을 설명하고 구현하는 데 사용할 수 있는 간략하고 기능적인 단위로 설계되어야 합니다. 이상적으로 접근 방식은 간결하고 명확해야 합니다. 길이가 길면 어떤 방식으로든 더 짧은 조각으로 나누는 것을 고려해 보세요. 이렇게 하면 클래스 내에서 코드를 쉽게 재사용할 수 있습니다(때때로 메서드가 매우 커야 하지만 여전히 동일한 작업만 수행해야 함).
5. 클래스를 설계할 때 클라이언트 프로그래머의 입장에서 생각해 보십시오(클래스 사용 방법이 매우 명확해야 합니다). 그런 다음 코드를 관리하는 사람의 입장이 되어 보세요. 어떤 종류의 변경이 이루어질지 예측하고 이를 더 간단하게 만드는 방법을 생각해 보세요.
6. 수업은 최대한 짧고 간결하게 진행하고 특정 문제만 해결하세요. 수업 설계에 대한 몇 가지 제안 사항은 다음과 같습니다.
1. 복잡한 스위치 문: "다형성" 메커니즘 사용을 고려하세요.
2. 많은 수의 메소드에는 매우 다양한 유형의 작업이 포함됩니다. 여러 클래스를 사용하여 별도로 구현하는 것을 고려하십시오.
3. 많은 멤버 변수는 매우 다른 특성을 가지고 있습니다. 여러 클래스를 사용하는 것을 고려하십시오.
7. 모든 것을 가능한 한 "비공개"로 만드십시오. 라이브러리의 일부(메서드, 클래스, 필드 등)를 "공개"로 만들어 절대로 제거할 수 없도록 할 수 있습니다. 강제로 내보내면 다른 사람의 기존 코드가 파괴되어 강제로 다시 작성하고 설계해야 할 수도 있습니다. 게시해야 하는 항목만 게시하는 경우 다른 항목을 자유롭게 변경할 수 있습니다. 다중 스레드 환경에서는 개인 정보 보호가 특히 중요한 요소입니다. 비공개 필드만 비동기화 사용으로부터 보호될 수 있습니다.
8. '거대물체증후군'을 조심하세요. 순차 프로그래밍 사고에 익숙하고 OOP 분야를 처음 접하는 일부 초보자의 경우 순차 실행 프로그램을 먼저 작성한 다음 이를 하나 또는 두 개의 거대한 개체에 포함시키는 것을 좋아하는 경우가 많습니다. 프로그래밍 원칙에 따르면 객체는 애플리케이션 자체가 아닌 애플리케이션의 개념을 표현해야 합니다.
9. 보기 흉한 프로그래밍을 해야 한다면 최소한 클래스 안에 코드를 넣어야 합니다.
10. 클래스가 매우 밀접하게 통합되어 있음을 발견할 때마다 코딩 및 유지 관리 작업을 개선하기 위해 내부 클래스를 사용할지 여부를 고려해야 합니다(14장, 섹션 14.1.2의 "내부 클래스를 사용하여 코드 개선" 참조).
11. 가능한 한 신중하게 주석을 추가하고 javadoc 주석 문서 구문을 사용하여 자신만의 프로그램 문서를 생성하십시오.
12. "마법의 숫자"를 사용하지 마십시오. 이러한 숫자는 코드에 잘 맞지 않습니다. 나중에 수정해야 한다면 "100"이 "배열 크기"를 나타내는지 아니면 "완전히 다른 것"을 나타내는지 알 수 없기 때문에 의심할 여지 없이 악몽이 될 것입니다. 따라서 상수를 생성하고, 설득력 있고 설명이 포함된 이름을 지정하고, 프로그램 전체에서 상수 식별자를 사용해야 합니다. 이렇게 하면 프로그램을 더 쉽게 이해하고 유지 관리할 수 있습니다.
13. 빌더 및 예외의 경우 일반적으로 해당 객체 생성이 실패하는 경우 빌더에서 발견된 예외를 다시 발생시키고 싶어합니다. 이렇게 하면 호출자는 개체가 올바르게 생성되었다고 맹목적으로 계속 생각하지 않게 됩니다.
14. 클라이언트 프로그래머가 객체 사용을 마친 후 클래스에 정리 작업이 필요한 경우 정리 코드를 잘 정의된 메서드에 배치하고 용도를 명확하게 나타내기 위해 cleanup()과 같은 이름을 사용하는 것을 고려하십시오. 또한 클래스 내에 부울 플래그를 배치하여 객체가 지워졌는지 여부를 나타낼 수 있습니다. 클래스의 finalize() 메서드에서 객체가 지워졌고 RuntimeException에서 상속된 클래스가 삭제되어(아직 삭제되지 않은 경우) 프로그래밍 오류를 나타내는지 확인합니다. 이와 같은 해결 방법을 사용하기 전에 finalize()가 시스템에서 작동하는지 확인하세요(이 동작을 확인하려면 System.runFinalizersOnExit(true)를 호출해야 할 수도 있습니다).
15. 특정 범위에서 객체를 지워야 하는 경우(가비지 수집 메커니즘에 의해 처리되지 않음) 다음 방법을 사용하십시오. 객체를 초기화하면 즉시 finally 절이 포함된 try 블록을 입력하여 정리 작업을 시작합니다. .
16. 초기화 프로세스 중에 finalize()를 재정의(취소)해야 하는 경우 super.finalize()를 호출하는 것을 잊지 마십시오(객체가 직접 슈퍼 클래스에 속하는 경우에는 필요하지 않습니다). finalize()를 재정의하는 과정에서 super.finalize()에 대한 호출은 기본 클래스 구성 요소가 필요할 때 여전히 유효한지 확인하기 위해 첫 번째 작업이 아닌 마지막 작업이어야 합니다.
17. 고정 크기 객체 컬렉션을 생성할 때 이를 배열로 전송합니다(특히 메서드에서 이 컬렉션을 반환하려는 경우). 이러한 방식으로 컴파일 타임에 배열 유형 검사의 이점을 누릴 수 있습니다. 게다가 배열의 수신자는 개체를 사용하기 위해 개체를 배열로 "캐스트"할 필요가 없을 수도 있습니다.
18. 추상 클래스 대신 인터페이스를 사용해 보세요. 어떤 것이 기본 클래스가 될 것이라는 것을 알고 있다면 첫 번째 옵션은 그것을 인터페이스로 바꾸는 것입니다. 메소드 정의나 멤버 변수를 사용해야 하는 경우에만 이를 추상 클래스로 변환하면 됩니다. 인터페이스는 기본적으로 클라이언트가 원하는 작업을 설명하는 반면, 클래스는 특정 구현 세부 사항을 전담(또는 허용)합니다.
19. 빌더 내부에서는 물체를 올바른 상태로 만드는 데 필요한 작업만 수행합니다. 가능할 때마다 다른 메서드를 호출하지 마십시오. 이러한 메서드는 다른 메서드에 의해 재정의되거나 취소되어 빌드 프로세스 중에 예측할 수 없는 결과가 발생할 수 있습니다(자세한 내용은 7장 참조).
20. 객체는 단순히 일부 데이터를 보유해서는 안 되며, 객체의 동작도 잘 정의되어야 합니다.
21. 기존 클래스를 기반으로 새 클래스를 생성할 경우 먼저 "새로 만들기" 또는 "만들기"를 선택하세요. 이 문제는 자신의 디자인 요구 사항을 상속해야 하는 경우에만 고려해야 합니다. 새로운 생성이 허용되는 곳에 상속을 사용하면 전체 디자인이 불필요하게 복잡해집니다.
22. 동작 간의 차이를 표현하려면 상속과 메서드 적용 범위를 사용하고, 상태 간의 차이를 표현하려면 필드를 사용하세요. 매우 극단적인 예는 다양한 클래스로부터의 상속을 통해 색상을 표현하는 것입니다. 이는 반드시 피해야 합니다. "색상" 필드를 직접 사용하세요.
23. 프로그래밍 시 문제를 방지하려면 클래스 경로가 가리키는 각 이름이 하나의 클래스에만 해당하는지 확인하십시오. 그렇지 않으면 컴파일러가 먼저 동일한 이름을 가진 다른 클래스를 찾아 오류 메시지를 보고할 수 있습니다. 클래스 경로 문제가 발생한 것으로 의심되는 경우 클래스 경로의 각 시작 지점에서 동일한 이름을 가진 .class 파일을 검색해 보십시오.
24. Java 1.1 AWT에서 이벤트 "어댑터"를 사용할 때 특히 트랩에 직면하기 쉽습니다. 어댑터 메서드를 재정의하고 철자법이 특별히 특별하지 않은 경우 최종 결과는 기존 메서드를 재정의하는 대신 새 메서드를 추가하는 것입니다. 그러나 이는 완벽하게 합법적이므로 컴파일러나 런타임 시스템에서 오류 메시지를 받지는 않지만 코드는 올바르게 작동하지 않습니다.
25. "의사 기능"을 제거하기 위해 합리적인 설계 솔루션을 사용하십시오. 즉, 클래스의 객체 하나만 생성해야 한다면 미리 애플리케이션에만 국한하지 말고 "그 중 하나만 생성하세요" 주석을 추가하세요. 이를 "외동 자녀" 형식으로 캡슐화하는 것을 고려해 보십시오. 자신만의 개체를 만드는 데 사용되는 기본 프로그램에 분산된 코드가 많이 있는 경우 이 코드를 캡슐화하는 창의적인 솔루션을 채택하는 것을 고려해 보세요.
26. "분석에 의한 마비"를 조심하세요. 무슨 일이 있어도 전체 프로젝트의 현황을 미리 파악하고 세부 사항을 검토해야 한다는 점을 기억하세요. 전반적인 상황을 파악하고 있기 때문에 알려지지 않은 몇 가지 요소를 빠르게 인식하고 세부 사항을 검토할 때 "죽은 논리"에 빠지는 것을 방지할 수 있습니다.
27. "조기 최적화"를 주의하세요. 먼저 실행하고 나중에 더 빨라지는 것을 고려하세요. 하지만 꼭 필요한 경우와 코드의 일부에 성능 병목 현상이 있다는 것이 입증된 경우에만 최적화하세요. 병목 현상을 분석하기 위해 전문적인 도구를 사용하지 않는 한 아마도 시간을 낭비하고 있을 것입니다. 성능 향상의 암묵적인 비용은 코드를 이해하기가 더 어려워지고 유지 관리가 더 어려워진다는 것입니다.
28. 코드를 작성하는 것보다 읽는 데 훨씬 더 많은 시간을 소비한다는 점을 기억하십시오. 명확한 디자인은 이해하기 쉬운 프로그램을 만들지만, 주석, 세심한 설명, 몇 가지 예는 종종 매우 중요합니다. 그것들은 당신 자신과 당신을 따르는 사람들 모두에게 매우 중요합니다. 여전히 의심스럽다면 온라인 Java 문서에서 유용한 정보를 찾으려고 노력하는 과정에서 좌절감을 느꼈다고 상상해 보십시오. 그러면 확신을 갖게 될 것입니다.
29. 분석이나 설계, 구현을 잘했다고 생각한다면 생각의 관점을 살짝 바꿔주세요. 반드시 전문가는 아니더라도 회사의 다른 부분에 있는 외부인을 초대해 보십시오. 완전히 새로운 눈으로 당신의 작업을 보고 당신이 보지 못했던 문제를 발견할 수 있는지 확인하도록 요청하십시오. 이 방법을 채택함으로써 우리는 수정에 가장 적합한 단계에서 몇 가지 핵심 문제를 식별할 수 있으며, 제품 출시 후 문제 해결로 인한 비용과 에너지 손실을 피할 수 있습니다.
30. 좋은 디자인은 최고의 수익을 가져올 수 있습니다. 즉, 주어진 문제에 대한 가장 적절한 해결책을 찾는 데 오랜 시간이 걸리는 경우가 많습니다. 그러나 일단 올바른 방법을 찾으면 향후 작업이 훨씬 쉬워질 것이며 몇 시간, 며칠, 몇 달 동안 고통스러운 어려움을 겪을 필요가 없을 것입니다. 우리의 노력은 가장 큰 보상(심지어 헤아릴 수 없는 보상이라도)을 가져올 것입니다. 그리고 많은 노력을 기울였기 때문에 마침내 훌륭한 디자인 계획을 얻게 되었고, 성공의 설렘도 짜릿합니다. 종종 노력할 가치가 없는 일을 서두르고 싶은 유혹에 저항하십시오.