OOD：オブジェクトの識別に問題があります

Question

これは簡単なものです。

私が非常に単純なタイムクロックアプリケーションを設計しているとしましょう。ユーザは自分のIDを入力し、アプリケーションは彼に1週間の時間を示し、1時間の時間を示し、その後、彼が私たちの中にパンチすることを可能にする。従業員が現在パンチインされているかどうかを知るには十分にスマートです。休憩や昼食やシフトなどはありません。

私は従業員を持っています。私は複数のEventRecordsを持つタイムカードを持っています。私はもちろん時間を維持するTimeclockを持っていますが、モデル全体（おそらく）のフロントエンドの一種です。

従業員がタイムカードを持っているか、タイムカードが従業員を参照していますか？

タイムカードは、その日の時間などを計算する責任がありますか？

タイムクロックは、従業員とタイムカードをインスタンス化して関連付ける必要がありますか？

TimeclockはpunchInとpunchOutを行うべきですか、それともEmployeeであるべきですか？

Answer 1

私はあなたが少しでも物理的なオブジェクトをここに拾っていると思います。従業員は、それが身分証明書を持っていてシナリオのプレイヤーであるため、おそらくオブジェクトとして持つのがよいでしょうが、私はタイムカードまたはタイムクロックのいずれかがオブジェクトとして良い候補には見えません。 Timecardは従業員に属するEventRecordsのリストに過ぎないので、従業員オブジェクトまたは集合リストにそれらを保持することもできます。 Timeclockはまったく何もしませんが、DateTime.Nowを渡します。

EventRecordは良いですか、おそらくWorkTimeオブジェクトである可能性があります。ペアまたはパンチインおよびパンチアウトの時間を含む。最後のレコードにパンチアウト時間がない場合、従業員はパンチインされます。

従業員オブジェクトの時間レコードを保持するか、個々の従業員を参照する個別のリストに保持することはむしろ趣味の問題です。

私はタイムカードとタイムクロックオブジェクトを破棄したので、ほとんどの質問は落ちます...;

Answer 2

エンドユーザの視点では、プログラマの視点からではなく、これらの質問に自分自身で答えてください。

従業員がタイムカードを持っているか、タイムカードが従業員を参照していますか？

誰がタイムカードを所有していますか？

*タイムカードはなど、その日のための時間を計算するための責任を負うべきか？**

万一それ？

タイムクロックは、従業員とタイムカードをインスタンス化して関連付ける必要がありますか？

時刻クロックは従業員をインスタンス化しますか？

TimeclockはpunchInとpunchOutを実行する必要がありますか？

同じ...

まず、あなたは問題を分析する必要があります。次に、ソリューションを設計してからコードを作成してください。

したがって、各プロセスを別のプロセスから分離する必要があります。ここでは、それはあなたが心の中で実装して分析した後、スティーブA. Loweのからthis answerを参照してくださいなど

設計しているようだ

、あなたの心の中で明確に持っていたら

どのオブジェクトあなたは、何の責任がある、と実装中少しだけあなたのデザインを調整し、それが理にかなっている場合はそれに適応させることができます。

経験が増えると、3つのプロセスがあなたの頭の中で本当に速く起こることがあります。しかし、あなたは忍耐しなければなりません。

Answer 3

これは、あなたのオブジェクト指向モデルが基本的に現実の世界を反映すべきである場合のまともな例です。

従業員がタイムカードを持っているか、タイムカードが従業員を参照すべきですか？

従業員にはタイムカードが必要です。リアルタイムのカードだったら、それを運ぶでしょう。あなたはタイムカードのポケットにいません。

タイムカードは、その日の時間などを計算する責任がありますか？

私はあなたが何を意味するか分かりません。チェックアウトからマイナスチェックまでの時間数を計算することを意味しますか？おそらくあなたのタイムカードができることです。

Timeclockは、従業員とタイムカードをインスタンス化して関連付ける必要がありますか？

おそらく。 「タイムクロック」とは何ですか？従業員のタイムカードの作成と関連付けについて考えるとき、私は「オフィス」のラインに沿ってもっと考えています。私はあなたのモデルの完全な範囲は、しかし、私はよく分かりません。

TimeclockはpunchInとpunchOutを行うべきですか、それとも従業員はすべきですか？

タイムカードが出入りするのを見たことはありますか？それが従業員の行動だと言ってもいいと思います。

編集：TheTXIが指摘したように、EmployeeはTimecardのpunchInメソッドとpunchOutメソッドを呼び出します。しかし、タイムカード自体は、いつパンチ・イン・アウトするのかを知る責任はありません。

Answer 4

注：ほとんどのモデリングと同じように、必ずしも1つの方法ではありません。

従業員は、タイムカードを持っている やタイムカードは 従業員を参照する必要がありますでしょうか？

ドメインは、従業員がタイムカードを持っていることを示唆しています（また、指摘されているように、時間の経過とともにタイムカードを超えています）。

タイムカードは、 の日数などの計算に責任がありますか？

私はそれをTimeCardCalculatorの再現性にします。

タイムクロックは、従業員と タイムカードをインスタンス化し、それらを関連付けるため 責任を負うべきか？

インスタンス化は、おそらくあなたのアプリケーションによって、より高いレベルで行われるべきだと思います。

TimeclockはpunchInを実行し、 punchOutを実行する必要がありますか？

TimeClock。従業員は、TimeClockでPunchIn/PunchOutを呼び出します。

Answer 5

ええ、この種のものはかなり古典的です。最も簡単なことは別のルールを適用することです。私のお気に入りはParnasの法則です。すべてのオブジェクトは、そのインターフェイスの背後にある要件で変更できるものを「隠す」ものです。

従業員に開始時刻と終了時刻の時間順リストであるTimeCardがあることは明らかです。

ドメインまで「時計入力」すると、「開始時間」のレコードが作成されます。 「クロックイン」や「クロックアウト」のようなサウンドはTimeCardの方法かもしれませんが、それについて考えると、おそらく要件変更が隠されています（たとえば、データベースのレコード、フラットファイルのライン、現地時間、GMT、またはUNIX時間を保存していますか？）

従業員は従業員の代表であり、従業員固有の情報をすべて含んでいます。

今のところ、外の世界のドメインでのクロッキングの「実装」を除いて、TimeClockの必要性は明白ではありません。

アプリケーションをビルドするときに、ドメインからビルドする必要があります。ここで、何らかのUI、認証する方法（必要なEmployeeを確立する方法）、Employee's TimeCard - 従業員のための方法を示唆しています。次に、UIに「クロックイン」と「クロックアウト」する場所が必要です。これは、timeClockが実装内のViewオブジェクトであるかのように見えます。いくつかのボタンと、あなたのログインプロトコルが何であれ必要です。

「ビジネスプロセス」または「最初にログインしてから、後でクロックアウトしてからログアウトする」などがあります。コントローラがあります。どのように分割するかは、UIの操作方法に多少依存します。