"그 개념이 비록 인스턴스 변수만 포함하더라도 개념을 명시적으로 표현하는 것은 전체적인 설계의 명확성과 유연성을 높이는 첫걸음이다."
"어떤 클래스가 필요한지를 고민하기 전에 어떤 객체들이 필요한지 고민하라. 클래스는 공통적인 상태와 행동을 공유하는 객체들을 추상화한 것이다. 따라서 클래스의 윤곽을 잡기 위해서는 어떤 상태와 행동을 가지는지를 먼저 결정해야 한다. 객체를 중심에 두는 접근 방법은 설계를 단순하고 깔끔하게 만든다."
떠오른 아이디어
@YJGwon 가 첫모임에서 말했던 내용과 비슷한 내용이 나오더라고요!
여기에서 아이디어를 얻어 서포터즈 객체 설계할 때 도움이 되었습니다!
서포터즈 설계를 하고 코드를 만들면서 오류를 범하게 됩니다.
어떤 객체가 필요한지 고민하지 않고 어떤 클래스가 필요한지만 생각했다는 것
클래스부터 고민하니 설계가 틀에 갇히는 것 같더라고요!
담당자 분께 전달받은 엑셀의 데이터 형식에 생각이 묶여서 supporter라는 클래스를 엑셀에 적혀있는 필드값을 그대로 넣어 만들었다는 점
그래서 다른 객체로 떼어낼 생각을 더 못했었던 것 같아요.
다음부터는 담당자 님이 주시는 자료(엑셀 등)는 그냥 비즈니스를 이해하기 위한 참고 용도로만 봐야겠어요!
비즈니스를 이해하고 이해한 내용을 바탕으로 객체와 또 그 객체들이 어떤 상태와 행동을 가지는지를 먼저 고민하는 것이 좋아보입니다!
위와 같은 고민의 과정을 거쳐 떼어낼 수 있는 객체를 떼어내보자는 생각을 하게 됐습니다.
서포터즈 기수라는 객체를 분리해 로직이나 UI 상으로도 데이터 등록, 조회가 훨씬 개선된 구조로 변경되었어요!!
문구
떠오른 아이디어
@YJGwon 가 첫모임에서 말했던 내용과 비슷한 내용이 나오더라고요!
여기에서 아이디어를 얻어 서포터즈 객체 설계할 때 도움이 되었습니다!
서포터즈 설계를 하고 코드를 만들면서 오류를 범하게 됩니다.
supporter
라는 클래스를 엑셀에 적혀있는 필드값을 그대로 넣어 만들었다는 점위와 같은 고민의 과정을 거쳐 떼어낼 수 있는 객체를 떼어내보자는 생각을 하게 됐습니다.
서포터즈 기수라는 객체를 분리해 로직이나 UI 상으로도 데이터 등록, 조회가 훨씬 개선된 구조로 변경되었어요!!