Intro

In a series of posts I radically complain about where time/efficiency is lost and shamelessly quote what other developer/heroes have said before. I spice this up with my own stories of inefficiency. Inefficiency, that when avoided, could be then replaced by throwing rubber ducks or whatever pleasantries you young folks do these days.

I hope my stories may make your day more effective. And you grow to be the creating god you aspired to be in the first place.

Informal: A lot of time is lost on tracking/finding the bugs which can be resolved by failing early.

This means that we avoid an incorrect state early in the process. eg. user.setEmailAddress(15) shouldn’t be allowed. It should tell me this is wrong and it should tell me early. But why bother?

If for some obscure reason, possibly alcohol poisoning, you supply the name in the user emailAddress field this might get stored in your database. You might find yourself finding out you have problem only after sending emails to this user. It is well possible that the problem hides for hours, days or even months. You will have a very bad time fixing this data corruption problem.

Formal

Theorem: The time invested in avoiding incorrect state by only allowing correct objects outweighs the time invested in root cause analysis. By correct objects we mean objects that obey all business rules.

Only allowing correct objects removes the need to validate the object at different points in the code. The object validates and keeps a correct state at all time.

Creating an invalid object, and thus breaking business rules, is impossible when factories or constructors safeguard it.

It is possible to create a program that does obey the business rules without factories/constructor tricks. Sadly however it opens up for duplication, inconsistency or total lack of validation.

For one I once had to refactor an entire code base just to add the following business rule:

Every user must be in at least one user group.

Every test that required a user would also require a group now. Hours of good development time was lost that day. Validation would ruin everything. Now each time validation is added, old tests that have started breaking, need to be fixed.

It’s horrible to be fixing tests because they aren’t obeying your business rules. It makes sense to keep your objects as simple as possible, in my case it ruined everything.

Why not validate objects by other validator objects?

This means you can create corrupt objects. Objects that don’t make any sense might escape your validation process. Programmers that don’t know of this class may circumvent it, be it on purpose or not.

Another possible solution is to have a layer where potentially corrupt objects are allowed. And further layers don’t allow corrupt objects. The options for bad corruption are still open.

Validation towards users should happen at the technical level. For instance if you have a form that needs to show invalid fields, like invalid email address.