When implementing a class, defensive programming should be considered. These techniques are likely to make your program not compile, which is a benefit. Problems are isolated at compile time and not later. Early discovery is always better. This is an example of not taking shortcuts simply to compile your program. Fight that temptation. Instead, force problems to compile time. It is less expensive to have the compiler find your problems than a customer—and definitely better for your brand.
The fully abstract class is an important concept in object-oriented analysis and design (OOAD). It is also important for defensive programming. A fully abstract class exposes an interface and hides the details. The interface is the public functionality of the class. Controlling access to the state of a class prevents inappropriate usage of the details (i.e., data members). Exposed data members can be changed far away from the class implementation, where the context is missing. This is where a mistake is likely to occur. A fully abstract class prevents this. Data members must be changed in member functions. In the member function, which is implemented in the class, the context is obvious.
Proper modifiers on a class are an important step in defensive programming. Class modifiers form an invaluable check on the intent of the class designer and developer. For example, a class designated as abstract in design should be decorated with the abstract modifier at implementation. Any attempt to create an instance of the abstract class will now cause a compile error, which is appropriate. Another example would be members with static content. Prefix those members with the readonly or const modifier, depending on when initialization occurs. If you later forget the intent of the member and assign the member a value, an error will occur at compilation. You catch the problem early.
The separation of interface and implementation is an important tool in defensive programming. A clear view of the interface is helpful in using the type correctly. Separating the interface from the implementation provides that. The code from the implementation, particularly for a large class, distracts from the interface, which can lead to improper use of the class. The interface should be clearly visible. For C++ developers, header files provided this clarity. This is the reason why header files are consistently used in C++ code, even though header files are technically optional.
For developers of libraries, there is an extra benefit to using the interface. You can expose the interface and not the actual object. This limits access to the actual object.
You can also expose a subset of available behavior of an object through an interface. Exposing discrete interfaces allows a developer to expose behavior based on context. If there was an Amphibious class, it would have two interfaces: IAuto and IBoat. Based on the usage (land or water), you could expose one of the two interfaces. (See the following code.) Limiting behavior to a specific context with an interface is a good defensive programming technique. This restricts the object to proper behavior based on the usage. Any attempt at other behavior would cause a compile error.
Look at the following sample code. The Amphibious class has ICar and IBoat interfaces.
public interface ICar{
bool Start();
bool Accelerate();
bool Turn();
// other methods
}
public interface IBoat {
bool Start();
bool Accelerate();
bool Turn();
//other methods
}
internal class Amphibious : ICar, IBoat {
//interface method implementation
}
public abstract class Boat {
public static IBoat GetBoat() {
return new Amphibious();
}
public static ICar Convert2Car(IBoat obj) {
return (ICar) obj;
}
}Here is the Amphibious class being used:
IBoat myBoat = Boat.GetBoat(); myBoat.Start(); ICar myCar = Boat.Convert2Car(myBoat); myCar.Turn();