롱런 프로젝트 (3) 썸네일형 리스트형 빌더 패턴에 생성자 파라미터를 강제하거나 강제하지 않을 때 빌더 패턴을 사용하면 private 생성자에 중첩 클래스인 Builder 클래스을 통하여 해당 필드값을 채워 넣는다. 빌더 패턴은 클래스의 필드값이 여러개인데 (좀 많을 때) 해당 필드값들이 모두 필요하지 않을 때 자주 사용된다. Effective Java 3/E - item2 "점층적 생성자 패턴도 쓸 수는 있지만, 매개변수 개수가 많아지면 클라이언트 코드를 작성하거나 읽기 어렵다." 현 프로젝트에서는 Study 객체의 정보를 담당하기 위한 StudyCondition 클래스를 정의하는데 이 정보들이 모두 필요하지 않았다. 게다가 이 객체를 활용하여 Study 객체를 비교하거나 필터링 하는데도 유용하게 사용할 수 있을 거라 생각했다. 그래서 StudyCondition 객체를 Builder 패턴으로 정의했.. 컬렉션을 활용한 객체를 사용할 경우 Volunteer 라는 클래스를 정의하고 지원자들을 모아 비교하고 확인하는 로직 또한 필요하기 때문에 컬렉션으로 묶는 VolunteerSet 또한 정의했다. 일단 컬렉션으로 묶은 필드를 포함하는 클래스를 정의할 때, 즉 래핑한 해당 컬렉션의 장점은 컬렉션에서 정의한 공개 메서드들을 통제할 수 있다. 그리고 래핑한 클래스의 이름을 가독성 좋게 짓는다면 그 또한 장점이라 할 수 있다. 내부 캡슐화도 된다. 이때 컬렉션에서 주로 사용되는 메서드들이 객체 내부적으로 사용하는 메서드가 있다. 바로 equals 와 hashCode 메서드다. 이 메서드를 재정의 해야 래퍼클래스에서 사용하는 동작들을 커스텀 할 수 있다. 현 프로젝트를 예시로 든다면 Volunteer 클래스의 equals 와 hashCode 는 해당 .. 인터페이스와 추상 클래스를 함께 쓴다면 인터페이스 설계 도중 1. interface Group class Study implements Group enum StudyType 으로 설계 후 Study 에서 StudyType을 필드로 갖는 방법 2. interface Group abstract class Study implements Group class LectureStudy extends Study class DebateStudy extends Study 으로 설계 후 구현하는 방법 두가지 관점에서 고민을 했다. 1번 경우를 사용하면 새로운 타입이 추가될 때 열거 타입에 추가되는 객체를 추가하면 쉽게 처리되지만 새로운 타입의 정의에 따라 달라질 수 있는 필드 또는 상태가 추가 될경우 ( 여기선 Lecture 일 때 가르치는 사람 필드가 필요했.. 이전 1 다음
