Question

Suppose you have a subsystem that does some kind of work. It could be anything. Obviously, at the entry point(s) to this subsystem there will be certain restrictions on the input. Suppose this subsystem is primarily called by a GUI. The subsystem needs to check all the input it recieves to make sure it’s valid. We wouldn’t want to FireTheMissles() if there was invalid input. The UI is also interested in the validation though, because it needs to report what went wrong. Maybe the user forgot to specify a target or targetted the missles at the launchpad itself. Of course, you can just return a null value or throw an exception, but that doesn’t tell the user SPECIFICALLY what went wrong (unless, of course, you write a separate exception class for each error, which I’m fine with if that’s the best practice).

Of course, even with exceptions, you have a problem. The user might want to know if input is valid BEFORE clicking the “Fire Missles!” button. You could write a separate validation function (of course IsValid() doesn’t really help much because it doesn’t tell you what went wrong), but then you’ll be calling it from the button click handler and again from the FireTheMissles() function (I really don’t know how this changed from a vague subsystem to a missle-firing program). Certainly, this isn’t the end of the world, but it seems silly to call the same validation function twice in a row without anything having changed, especially if this validation function requires, say, computing the hash of a 1gb file.

If the preconditions of the function are clear, the GUI can do its own input validation, but then we’re just duplicating the input validation logic, and a change in one might not be reflected in the other. Sure, we may add a check to the GUI to make sure the missle target is not within an allied nation, but then if we forget to copy it to the FireTheMissles() routine, we’ll accidentally blow up our allies when we switch to a console interface.

So, in short, how do you achieve the following:

1. Input validation that tells you not just that something went wrong, but what specifically went wrong.
2. The ability to run this input validation without calling the function which relies on it.
3. No double validation.
4. No duplicate code.

Also, and I just thought of this, but error messages should not be written in the FireTheMissles() method. The GUI is responsible for picking appropriate error messages, not the code the GUI is calling.

Answer 1

“The subsystem needs to check all the input it receives to make sure it’s valid”

Think of the inputs not so much as a list of arguments, but as a message, it gets easier after that.

The message class has an IsValid member function, it remembers if IsValid was called and what the result was. It also remembers its state, if the state changes then it needs to be re validated. This message class also keeps a list of validation errors.

Now, the UI builds a TargetMissiles message, and the UI can validate it, or pass it directly to the MissileFiring subsystem, it checks to see if the message was validated, if not it validates it, and proceeds / fails depending.
The UI gets the message back, with the list of validations already populated.

The messages with their validation sit in a separate library. No code is duplicated.

This sound OK?