Something else I wanted to ask is, do you construct functions with the absolute assumption that the data being given into the function is valid and within the bounds of the function? Is it generally good practice to make functions that test data (not necessarily input validation) to be washed clean before entering a function, or do you prefer to take the data into the function, test if the data is good in the function, and act accordingly?
Here's an example. For this movie ticket buying program, users could only buy contiguous seats on one row at a time. So if you wanted 5 contiguous seats on row 3 that are available, you can order them, but if you wanted other seats on another row as well, you'd have to do that in a separate ordering instance. I decided that before I even allow the user to buy tickets, I determine what is the largest set of contiguous seats in the theater. I then tell the user that they can enter between 1 to however many the max contiguous seats is for that case. That way, if the user says they want to order 1,000,000 seats, I don't even bother going into the checkSeats() function. I just stop them right away and ask for a new number of tickets. The alternative would be to go into the checkSeats() function and see if I can find those 1,000,000 seats for them.
I know that programming is never a cook-book answer, and that different cases will have different solutions. But I am curious how people feel about this in a general case. Do you try to filter only valid data into a function as a standard until it is not feasible or unneeded, or do you only do it when you feel it is necessary?
Regarding your second paragraph, you're going to find that you'll need to go into checkSeats() anyway upon input, as your data could have changed. Other users could have reserved or cancelled, and that could change your total number of available contiguous seats by the time any other user finalizes his or her selection. Certainly, running some checks up front to limit the inputs can be of value, but it doesn't absolve you of the need to check afterwards.
In more general terms of your first paragraph, I view it like this: if you have a public method, that method should verify (or delegate the task of verifying) the inputs for logical correctness. I don't care if another public method elsewhere has validated those same inputs -- by nature of the method being public, anybody can call it, so you can't guarantee input vectors. The last thing you want is your code to blow up because you didn't take a moment to validate against a null or a negative number or some other invalid argument. Your private methods should then not need to worry about validation (unless, of course, validation is their job) (this is assuming your code is well designed and that you trust
yourself to give
yourself good values -- and by "yourself," I really mean the class, not the author of it).
At the same time, if you're calling into a public method and you haven't already validated the inputs you're using (such as, you got them from a user or even a database), then validate before even calling. Look at it as if you're consuming a library, ignoring for a moment that you might have been the author of it. If you know that the library could potentially bomb because of what you pass it, you want to validate what you're passing. The last thing you want is for your program to fail unexpectedly, and quite often a source of failure is invalid data.
It might sound as if I'm saying have validation code all over the place, repeatedly, and I'm really not. If your program is well designed, your validation will be isolated. I simply advocate that the code being consumed validate arguments before working with them, and the consuming code validate parameters before sending them, particularly when the source of those parameters can't be trusted (as in, the data came from an external source).
In code terms, if you have a method that looks like (examples provided in C#/.NET):
Code:
public int Divide(int numerator, int denominator)
{
if (denominator == 0) throw new ArgumentException("Denominator cannot be 0.");
return numerator / denominator;
}
This is public method that will blow up with a particular input. If you're consuming that method, you do not want to provide that input! So you validate beforehand
Code:
int numerator = GetNumeratorFromSomewhere();
int denominator = GetDenominatorFromSomewhere();
int quotient;
if (denominator > 0)
{
quotient = someObject.Divide(numerator, denominator);
}
This is what I mean by validation on both sides. You don't want to accept bad arguments, but you also want to be good citizen and not send them.
