Specifying the Method Conditions

PreConditions

You have previously worked your way through creating a simple program that used simple methods to draw pictures. In essence, each method was a stand-alone command and you typed the number of methods you needed in the correct sequence needed to create the asterisk box. It was important for you to get through that process because the sequencing and application of methods in your programs is what programming is about. However, there are ways to make the methods more powerful and effective so that your program development is both easier and more efficient. Consider the following.

Preconditions. The first thing you need to know or decide is what the preconditions for your method design will be. If someone has told you what the preconditions will be, you can just follow her rules and design your method as needed. However, many times you will be the one designing the whole program, so as you design your methods you need to know what your method can, or might be required to, handle.

Say for example that you are writing a method to divide two numbers. A precondition should be that the divisor will never be zero when this method is used. If there is a chance that the divisor will be zero, your method must be able to adapt to that condition.

Another example would be a method that calculates factorials. Since the highest normal integer can only reach to about 2⁶⁴ (on most computers), your method may crash the program or return bad data if the answer is greater than this limit allows. This means that if a number that is too large is entered to be factorialized, there will be a problem.

Other example preconditions:

• method will be passed a string containing a user prompt (meaning it will not be passed an integer or a double value)
• method will never be passed a negative number
• method will only be passed an integer value
• etc

The key to preconditions is that you will design your method with the expectation that the input or starting conditions will be correct within certain constraints, or you will design your method to respond to the inappropriate conditions. More about this later.

So, how do you decide what the preconditions should (and maybe shouldn't) be?

Go back to the previous division method example. If you have a method that is supposed to divide one number by the other, what will the method need to know? It will be assumed that the method itself will know how to divide numbers, but it won't automatically know which numbers to divide. Therefore, you will decide to send it a divisor and a dividend, shown in the following prototype.

   public double divideTwoNumbers( double divisor, double dividend );

Your factorial method will know how to implement the factorial action, but that will only require the number to be factorialized and it doesn't need anything else. The “What’s the same?” and “What’s different?” questions are asked and you find that this method only needs to accept one value, as shown in the following prototype.

   public double calcFactorial( double value );

One more example. Consider a situation where your method calculates and adds a sales tax to a sales subtotal. The method will need to know the subtotal and the tax rate. However, most commonly the tax rate is a global or class constant, and these constants do not need to be passed to methods because they are in scope (i.e., available) everywhere in the source code. Therefore the method preconditions will be that the subtotal is passed to the method, and that the tax rate will be available as a class or global constant, yielding the following method prototype. The “What’s the same?” question is that the tax, which is always the same in the program, will always be multiplied by the subtotal. The “What’s different?” question is that the subtotal will be different with each call of the method.

   public double calcTotal( double subtotal );

Once you have figured out the preconditions for a method, you can decide what you need for input to the method. Deciding, and then specifying (i.e., creating a specification for) the input for each method will be required for all methods you write.

Watch this video to see more examples of the Pre-Condition assessment leading to method inputs.