Comments on: Inheritance is Evil: The Epic Fail of the DataAnnotationsModelBinder

By: Michael Valenty

Michael Valenty — Wed, 20 Apr 2011 23:25:03 +0000

The function AddValidationErrorsToModelState could for example, loop over the properties of the model and validate the values against the validation attributes. This class shouldn’t also do the model binding, it should stick to the single responsibility of validation. They are unrelated concerns and there clearly are times when I would like one behavior without the other.

The author went to great lengths to build out an extensible model binder. The problem is that it’s a difficult task to guess all the ways that something might be used. It’s safer to stick to one thing and do it well, that way when new requirements creep up, they can be composed rather than trying to force it into an extensibility model that didn’t consider what you are trying to do.

By: cDima

cDima — Wed, 20 Apr 2011 15:43:48 +0000

Awesome post. But how would this call tie into the MVC DataAnnotation model?

AddValidationErrorsToModelState(model, controllerContext);

By: Refactoring C# Style | Agile at Work

Refactoring C# Style | Agile at Work — Sat, 27 Nov 2010 23:39:58 +0000

[...] convenience methods on the IUnitOfWork interface and implement them in an abstract base class, but inheritance is evil and it’s a tradeoff we don’t have to make in C#. This entry was posted on Saturday, November [...]

By: tmont

tmont — Wed, 06 Jan 2010 07:01:10 +0000

I think the point is that mutable members shouldn’t be exposed to derived class. As in, getFoo() should be public/protected and setFoo() should be private (except in certain cases like a DTO or something).

But of course, the whole point of inheritance is to reuse code, so a lot of the time you want encapsulation around the object rather than the class. If that’s not what you’re after, than you’re better off with something like a decorator or a composite.

Inheritance is only evil if used incorrectly, as Mike so eloquently illustrated in the case of the DataAnnotationsModelBinder.

By: Michael Valenty

Michael Valenty — Wed, 06 Jan 2010 01:22:40 +0000

It would be less bad in that your subclass wouldn’t rely on details of the base class, but the more important issue is that you lose out on composition.

By: Asaph

Asaph — Wed, 06 Jan 2010 00:43:45 +0000

You say:

“Your base class breaks encapsulation by exposing implementation details to subclasses in the form of protected members”

Would the situation be any better if we used private members instead of protected?