OOD : 개체 식별 문제

Question

이것은 간단한 것이어야합니다.

매우 간단한 timeclock 응용 프로그램을 설계한다고 가정 해 봅시다. 사용자는 자신의 ID를 입력하고 응용 프로그램에 한 주 동안 시간을 ​​표시하고 그 시간 동안 시간을 ​​표시 한 다음 우리가 밖으로 빠져 나올 수있게합니다. 직원이 현재 펀치를 받았는지 여부를 알만큼 충분히 똑똑합니다. 휴식이나 점심 또는 교대 또는 기타가 없습니다.

그래서 직원이 생겼습니다. 여러 개의 EventRecords가있는 Timecard가 있습니다. Timeclock은 물론 시간을 유지하지만, 전체 모델의 프론트 엔드 일 수도 있습니다 (아마).

직원이 근무 시간 기록표를 가지고 있거나 근무 시간 기록부가 직원을 참조해야합니까?

타임 카드가 당일 등을 계산해야합니까?

Timeclock이 직원 및 시간표를 인스턴스화하고 이들을 관련시켜야합니까?

Timeclock이 punchIn 및 punchOut을 수행해야합니까, 아니면 Employee가해야합니까?

Answer 1

나는 당신이 여기 너무 육체적 인 물체에 푹 빠져 있다고 생각한다. 종업원은 신분증이 있고 시나리오의 플레이어이기 때문에 아마도 객체로서 가지고있는 것이 좋다. 그러나 나는 타임 카드 나 타임 클럭을 객체가 될 수있는 좋은 후보로 보지 않는다. Timecard는 직원에게 속한 EventRecord의 목록 일 뿐이므로 Employee 객체 또는 집단 목록에 유지할 수 있습니다. Timeclock은 아무것도하지 않고 DateTime.Now를 넘겨줍니다.

EventRecord가 좋거나 WorkTime 객체 일 수 있습니다. 한 쌍 또는 펀치 인 및 펀치 아웃 시간. 마지막 레코드에 펀치 아웃 시간이 없으면 직원이 펀치 인됩니다.

Employee 개체에 시간 레코드를 보관하거나 각 직원에 대한 참조와 함께 별도의 목록에 보관하는 것은 오히려 맛의 문제입니다 .)

Answer 2

프로그래머의 관점이 아닌 최종 사용자 관점에서 자신의 질문에 대답하십시오.

직원이 근무 시간 기록표를 가지고 있거나 근무 시간 기록표에 직원을 참조해야합니까?

누가 타임 카드를 소유하고 있습니까?

*

는 타임 카드는 등 하루 동안 시간을 ​​계산하기위한 책임을 져야 하는가? **

가해야합니까?

타임 클락은 직원 및 시간표를 인스턴스화하고 관련을해야합니까?

시간 시계는 직원을 인스턴스화합니까?

Timeclock은 punchIn 및 punchOut을 수행해야합니까, 아니면 Employee를 수행해야합니까? 같은

...

첫째, 당신은 문제를 분석해야합니다. 그런 다음 코드를 작성한 후에 만 ​​솔루션을 설계하십시오.

따라서 각 프로세스를 다른 프로세스와 구분해야합니다. 여기에 당신이 마음에 구현 분석 한 후 스티브 A. 로우에서 this answer를 참조 등

설계있어 보인다

당신은 당신의 마음에있는 명확한 일단

어떤 개체 당신은 어떤 책임 및 구현시 당신의 디자인을 약간 조정할 수도 있고, 그것이 의미가있는 경우 그것을 적용 할 수도 있습니다.

경험이 많으면 세 가지 과정이 실제로 일어날 수 있습니다. 그러나 환자는 인내심을 가지고 있어야합니다.

Answer 3

OO 모델이 기본적으로 실제 세계를 반영해야하는 경우의 예입니다.

직원에게 근무 시간 기록표가 있습니까, 아니면 근무 시간 기록표에 직원을 기록해야합니까?

직원에게는 시간 기록표가 있어야합니다. 실시간 카드라면 휴대 할 수 있습니다. 네가 타임 카드 주머니에 들어 가지 않을거야.

시간 계산에 시간을 계산해야합니까?

나는 당신이 무슨 뜻인지 모르겠다. 체크 아웃에서 마이너스 체크인까지의 시간을 계산하는 것을 의미합니까? 이것은 아마도 귀하의 타임 카드가 할 수있는 일입니다.

타임 클락은 직원 및 시간표를 인스턴스화하고 이들을 관련시켜야합니까?

아마도. "Timeclock"이란 정확히 무엇입니까? 직원을 생성하고 시간표와 연관시키는 것을 생각할 때, 나는 "Office"의 라인을 따라 생각합니다. 그래도 모델의 전체 범위가 무엇인지는 잘 모르겠습니다.

Timeclock이 punchIn 및 punchOut을 수행해야합니까, 아니면 Employee를 수행해야합니까?

시간표를 본 적이 있고 본 적이 있습니까? 그게 직원의 행동이라고 말하는 것이 안전하다고 생각합니다.

편집 : TheTXI가 지적했듯이 직원은 Timecard에서 punchIn 및 punchOut 메소드를 호출합니다. 그러나 타임 카드 자체는 펀치 인 또는 펀치 아웃시기를 알지 못합니다.

Answer 4

참고 : 대부분의 모델링과 마찬가지로 항상 단일 방식으로 수행 할 수있는 것은 아닙니다.

는 직원이 타임 카드, 을해야하거나 타임 카드는 직원을 참조해야합니까?

도메인에서는 직원에게 시간 기록표가 있고 (시간이 지남에 따라 시간표 이상으로 표시됨) 제안합니다.

타임 카드는 일 계산 시간 등을 담당해야합니까?

나는 TimeCardCalculator의 재사용 가능성을 확인했습니다.

는 Timeclock는 임직원 일한를 인스턴스화하고 관련된에 대한 책임을 져야 하는가?

인스턴스화가 더 높은 수준에서 수행되어야한다고 생각합니다.

Timeclock이 punchIn을 수행하고 punchOut을 수행해야합니까, 아니면 Employee가되어야합니까?

TimeClock. 직원은 TimeClock에서 PunchIn/PunchOut을 호출합니다.

Answer 5

예, 이런 종류의 것은 꽤 고전적입니다. 가장 쉬운 방법은 다른 규칙을 적용하는 것입니다. 제가 가장 좋아하는 것은 Parnas의 법칙입니다. 모든 객체는 인터페이스 뒤에있는 요구 사항에서 변경할 수있는 것을 "숨 깁니다".

직원들에게 시작 시간과 종료 시간의 시간순 목록 인 TimeCard가 있음이 분명합니다.

도메인까지 "시계를 넣을"때 모든 작업은 "시간 시작된"레코드를 만드는 것입니다. "clock in"및 "clock out"과 같은 사운드는 TimeCard 메서드 일 수 있으며, 우리가 그것에 대해 생각할 경우 요구 사항의 변경 사항도 숨길 수 있습니다 (예 : 데이터베이스의 레코드, 플랫 파일의 라인 및 현지 시간, GMT 또는 UNIX 시간을 저장하고 있습니까?)

직원은 직원을 대표하고 모든 해당 직원 관련 정보를 포함합니다. 이름, 주소 등등.

지금까지는 외부 세계에서 클럭킹의 "구현"을 제외하고는 TimeClock이 필요하지 않습니다.

이제 응용 프로그램을 빌드 할 때 도메인에서 빌드해야하지만 이제는 어떤 종류의 UI가 필요합니다. 인증 방법 (원하는 Employee 설정)과 Employee 's TimeCard - 직원을위한 방법을 제안합니다. 그런 다음 UI에서 "클럭 인"및 "클럭 아웃"할 장소가 필요합니다. 마치 timeClock이 구현에서 View 객체가 될 것처럼 소리가납니다. 몇 개의 단추와 로그인 프로토콜이 필요합니다.

"비즈니스 프로세스"또는 "처음 로그인 한 다음 나중에 시계 아웃, 로그 아웃"또는 이와 유사한 항목이 하나 더 있습니다. 컨트롤러가 있습니다. 어떻게 분리했는지는 UI 수행 방법에 다소 좌우됩니다.