Good post, but as OO-evangelist I must disagree in general concept:P

Solution has a leaky abstraction problem: If you change inner impl of Order class than You have to change Validator interface - here is where abstraction leaks. Of course we can assume that Validator is kind of Visitor Patterns and live with this.

But don't get me wrong... I thing that Your solution is best of all possible. But if it still has a problem than i suspect that we are fighting WRONG PROBLEM here.

Your approach solves problem defined like this "there are different validation rules in system". Problem is defined probably by someone who does not think in OO, so it forces You to solve wrong thing:)

We must consider if this kind of problem is not a symptom of wrong architecture. I assume that if there different validation rules than we have different domains. (Bounded context in the meaning of of Eric Evans' DDD). If so, than need to model them using specific Order Classes - each specific for context.

My assumptions may be wrong, and someone can present specific counter-example. But as we discuss on general level it is worth to mention typical antipattern: common_enterprise_monter_anemic_model. It looks something like that: we have multiple modules (ex invoices, ordering, shipping, etc) covered with one common (and meaningless) anemic model.

According to getetrs/setetrs. It is nothing wrong if class is meant to to play role of stupid data transfer objects. For example as data-packet to communicate between bounded context. Ok, let i be, but where is the real model? Problem begins when official platform promotes this role (dto) as domain model:)

Sławek
http://art-of-software.blogspot.com