radarbob

no idea what you are talking about => No where did I say or suggest that constructor parameter validation is not needed. Separating it from the class it belongs to is de-facto bad design.

We do not know what IAggregateRoot looks like but I assume some or all are reflected in Attendance constructor parameters. In this solution I don't know how to reconcile the interface and 2 different constructor signatures without explicitly defined constructor parameters. .... The OP's suggestion of constructor overloads seems a better alternative.

Referring to times/dates is usually stated as "earlier than" or "later than", rather than "less than" or "greater than". Yeah, I know. It's an exception, "not for customer consumption" kinda thing. Just sayin'

Creating a different interface - IShiftValidator - and implementing it in a separate class - together and separately breaks the coherence of the AttendanceFromTo ( or Attendance ) class. Validating Attendance constructor inputs in a different class? No. Just no. Given that, a separate interface definition , even if implemented in `Attendance, is pointless.

C# interfaces cannot declare constructors. Thus create a different implementation of IAggregateRoot that accepts only hours is impossible. Besides, this interface declares only properties. We know this because Attendance : IAggregateRoot class has no methods.

Love the answer yet I stopped after the killer intro. Suddenly, underneath the OP question, I gleaned a fundamental not understanding of objects. This invisible hand treats OOD/P like a JC Whitney parts catalog. At the end of which in bold letters is written SOME ASSEMBLY REQUIRED.

Typical management, ignoring design time. We would have, ideally, designed out the repetitiveness prior to coding. Instead, management thinks development is a single Olympic event - coding - when it is in fact a decathlon. And they measure to 1/1000 of a second because they think it's all linear.

OO-wise this is a spilled cup. It's all over the place. You've got everything except a CupOfCoffee. The "dispenser" in the title can only be inferred w/in the spillage.

RE: the variation of the visitor pattern.... Made me think about IEnumerable - it returns an enumerator object without exposing the object being iterated. SO, what if we have Corrdinate.GetPositionTransformer() - returning a PositionTransformer object with the coordinate state pre-injected. I expect the implementation can keep the UI decoupled.

_ x and _y aren't really encapsulated any more. Admittedly splitting hairs here, but yes they are encapsulated. They are exposed in a specific context/meaning/use. They are not exposed for general consumption - i.e. that getter we're avoiding.