Your first stop on the road to interface awareness must be an examination of the problems that interface-based programming is
In an object-oriented paradigm, a client typically instantiates an object from a class. The client usually creates the object by using the
operator followed by the class
Dim Dog As CDog Set Dog = New CDog '*** Access a property. Dog.Name = "Snoopy" '*** Invoke a method. Dog.Bark
In this example, a class-based reference makes it possible to instantiate and communicate with a dog object. The communication between the client and the object takes place through a set of
One benefit of using classes is that they allow you to reuse code. Once a class has been written, you can use it in many different places in an application. Classes thus let you reduce or eliminate redundant code in an application. They also facilitate code maintenance. You can modify or remove any properties or methods that aren't publicly visible. You can also change public method
When you modify an existing class definition, you shouldn't change the calling syntax for accessing any public method or property because of the risk of breaking the dependencies that client code has built on the original class definition. As long as you hold the public interface constant, you can make any modifications to improve your class without breaking any client code.
To rephrase the key point of the last paragraph: Once you publish a property or a method signature in a class's public interface, you can't change or remove it. This means that you must properly design the public interface at the beginning of a project and use discipline as the class evolves. This lets you improve and extend object code without having to rewrite any client code. You can maintain a class by fixing
The rules for maintaining existing members of the public interface are cut-and-
Problems arise in class design when you change the signature of a public method in a way that breaks an existing client. This commonly happens when you discover that the initial class design was inadequate. For instance, imagine a method that provides the behavior for a dog rolling over. The following RollOver method is defined with a 16-bit integer parameter to allow the client to request a specific number of rolls in each invocation.
' Method defined in CDog class. Public Sub RollOver(ByRef Rolls As Integer) ' Implementation code goes here. End Sub ' Client hardcodes calling syntax. Dim Dog As CDog, Rolls As Integer Set Dog = New CDog Rolls = 20000 Dog.RollOver Rolls
What if the requirements of a dog object change weren't anticipated properly in the initial design? For instance, what if the required number of rolls exceeds the highest possible value for an integer (about 32 KB)? What if a client wants to invoke the method with the value 50,000? To accommodate a larger value, you must change the parameter type to a long integer. This creates quite a design problem. The
You have only two options. One is to modify the method signature and then rewrite all the client code that calls it. The other is to leave things as they are and deal with the limitations of the original design. As you can see, poor class design results in either broken clients or nonextensible objects.
The intuitive solution to this problem is to make sure that the design of the class's public interface is
The use of
results in a layer of dependencies between clients and classes. You can lessen the impact of these dependencies on maintainability and extensibility through disciplined design and by