- 생성자 대신 정적 팩터리 메서드를 사용할 수 없는지 생각해 보라
- 생성자 인자가 많을 때는 Builder 패턴 적용을 고려하라
- private 생성자나 enum 자료형은 싱글턴 패턴을 따르도록 설계하라
- 객체 생성을 막을 때는 private 생성자를 사용하라
- 불필요한 객체는 만들지 말라
- 유효기간이 지난 객체 참조는 폐기하라
- 종료자 사용을 피하라
- equals를 재정의할 때는 일반 규약을 따르라
- equals를 재정의할 때는 반드시 hashCode도 재정의하라
- toString은 항상 재정의하라
- clone을 재정의할 때는 신중하라
- Comparable 구현을 고려하라
- 클래스와 멤버의 접근 권한은 최소화하라
- public 클래스 안에는 public 필드를 두지 말고 접근자 메서드를 사용하라
- 변경 가능성을 최소화하라
- 계승하는 대신 구성하라
- 계승을 위한 설계와 문서를 갖추거나, 그럴 수 없다면 계승을 금지하라
- 추상 클래스 대신 인터페이스를 사용하라
- 인터페이스는 자료형을 정의할 때만 사용하라
- 태그 달린 클래스 대신 클래스 계층을 활용하라
- 전략을 표현하고 싶을 때는 함수 객체를 사용하라
- 멤버 클래스는 가능하면 static으로 선언하라
- 새 코드에는 무인자 제네릭 자료형을 사용하지 마라
- 무점검 경고(unchecked warning)를 제거하라
- 배열 대신 리스트를 써라
- 가능하면 제네릭 자료형으로 만들 것
- 가능하면 제네릭 메서드로 만들 것
- 한정적 와일드카드를 써서 API 유연성을 높여라
- 형 안전 다형성 컨테이너를 쓰면 어떨지 따져보라
- int 상수 대신 enum을 사용하라
- ordinal 대신 객체 필드를 사용하라
- 비트 필드(bit field) 대신 EnumSet을 사용하라
- ordinal을 배열 첨자로 사용하는 대신 EnumMap을 이용하라
- 확장 가능한 enum을 만들어야 한다면 인터페이스를 이용하라
- 작명 패턴 대신 어노테이션을 사용하라
- Override 어노테이션은 일관되게 사용하라
- 자료형을 정의할 때 표식 인터페이스를 사용하라
- 인자의 유효성을 검사하라
- 필요하다면 방어적 복사본을 만들라
- 메서드 시그니처는 신중하게 설계하라
- 오버로딩할 때는 주의하라
- varargs는 신중히 사용하라
- null 대신 빈 배열이나 컬렉션을 반환하라
- 모든 API 요소에 문서화 주석을 달라
- 지역 변수의 유효범위를 최소화하라
- for 문보다 for-each문을 사용하라
- 어떤 라이브러리가 있는지 파악하고, 적절히 활용하라
- 정확한 답이 필요하다면 float와 double은 피하라
- 객체화된 기본 자료형 대신 기본 자료형을 이용하라
- 다른 자료형이 적절하다면 문자열 사용은 피하라
- 문자열 연결시 성능에 주의하라
- 객체를 참조할 때는 인터페이스를 사용하라
- 리플렉션 대신 인터페이스를 이용하라
- 네이티브 메서드는 신중하게 사용하라
- 신중하게 최적화하라
- 일반적으로 통용되는 작명 관습을 따르라
- 예외는 예외적 상황에만 사용하라
- 복구 가능 상태에는 점검지정 예외를 사용하고, 프로그래밍 오류에는 실행시점 예외를 이용하라
- 불필요한 점검지정 예외 사용은 피하라
- 표준 예외를 사용하라
- 추상화 수준에 맞는 예외를 던져라
- 메서드에서 던져지는 모든 예외에 대해 문서를 남겨라
- 어떤 오류인지를 드러내는 정보를 상세한 메세지에 담으라
- 실패 원자성 달성을 위해 노력하라
- 예외를 무시하지 마라
- 변경 가능 공유 데이터에 대한 접근은 동기화하라
- 과도한 동기화는 피하라
- 스레드보다는 실행자와 태스크를 이용하라
- wait나 notify 대신 병행성 유틸리티를 이용하라
- 스레드 안정성에 대해 문서로 남겨라
- 초기화 지연은 신중하게 하라
- 스레드 스케줄러에 의존하지 마라
- 스레드 그룹은 피하라
- Serializable 인터페이스를 구현할 때는 신중하라
- 사용자 지정 직렬화 형식을 사용하면 좋을지 따져 보라
- readObject 메서드는 방어적으로 구현하라
- 개체 통제가 필요하다면 readResolve 대신 enum자료형을 이용하라
- 직렬화된 객체 대신 직렬화 프락시를 고려해 보라
100자 이내의 짧은 글을 쓸 수 있는 게시판 제공. Dolphin Project에서 가장 메인 서비스는 예적금 시뮬레이터이므로, 다른 기능 구현은 차후로 미뤄뒀지만, 사용자와 소통할 수 있는 최소한의 기능은 제공하는게 맞다는 생각이 들어 아주 단순한 게시판 기능을 제공합니다. 사용자가 글을 쓰려면 로그인을 먼저 해야합니다. 글을 등록 후 삭제할 때 글 작성자를 식별할 수 있어야 하기 때문입니다. 게시판은 Dolphin Frontend Main 페이지에 자리잡았습니다. 사용자가 가장 먼저 만나게 되는 웹페이지이므로 적당하다고 생각합니다. 다음은 로그인을 하기 전 사용자가 볼 수 있는 메인 페이지입니다. 글 상단에는 작성일(MMM-dd-yyyy)과 작성자 고유번호(#numbers)가 노출됩니다. Dolphin 은 네이버 로그인을 사용하기 때문에, 사용자를 식별할 수 있는 정보는 저 고유번호가 됩니다. 하단에는 글 내용이 자리잡습니다. 스크린샷에서는 Hello, world!! 라는 문구가 보이네요. 글은 최대 100자까지 허용합니다. 버튼 두개(Newer, Older) 는 페이징 버튼인데, Newer는 최근페이지로 이동을 하며, Older는 지나간 글을 보는 페이징버튼입니다. 기본 페이지 사이즈는 20개입니다. 오른쪽으로 보이는 글 작성 폼은 현재 로그인 하기 전이므로 textarea 는 disabled 처리되어 있고 Login버튼이 자리잡고 있습니다. 다음은 사용자가 로그인 한 뒤의 메인페이지입니다. 변경된 부분은 사용자 고유번호 뒤에 Remove 버튼이 나타났습니다. 해당 글 작성자가 로그인한 사용자일 경우에만 보이게 됩니다. 오른쪽 글 작성 폼도 이제 활성화 되었습니다. 아주 단순한 Textarea 창과 Submit 버튼이 자리잡고 있습니다. 다음은 작성자가 아닌 다른 사용자가 로그인한 경우 입니다. 사용자 고유번호(#54097272) 옆에 Remove 버튼이...