Why the AssertionConcern is implemented as a base class?

[rantri]

AssertionConcern should be a reusable component and not a base class for every object that need to do assertions.
Composition Over Inheritance

It should be something like this:
https://github.com/phatboyg/Magnum/blob/master/src/Magnum/Guard.cs

[VaughnVernon]

Sure we can do that, but that's not composition. I don't mind using a set of static methods for this, yet the static methods in a helper class is not composition. In some ways inheritance is cleaner because it says that "I as an entity" or "I as a value object am concerned with asserting parameters to me an my state." It makes the statement that I as the object care about this. Still, I don't mind it myself if there is a good reason to make AssertionConcern a set of static method.

Since "Composition Over Inheritance" is not applicable in your suggestion, what is your good reason?

[Frikki]

I think that the static methods in a helper class approach solves a problem of multiple inheritance. For example, entities could be subclasses of a self-validator base class, but that would prevent them from also being subclasses of the AssertionConcern class, unless either would be a subclass of the other. However, you could quickly end up building classes with too much functionality.

What about injecting the AssertionConcern class into the entities?