Over the next 2 months, I'm presenting a session in the .NET community on interfaces. A popular INETA speaker has told people that they don't need to know about interfaces. While interfaces take time to learn and sometimes confuse developers, I strongly disagree with this advice.
A common definition/description of an interface is a contract that guarantees how a class will behave, and what properties and methods the class will contain. When you create an instance of a class that implements the interface, you can be assured that the class will contain every PEM that the interface defined. Think of the interface as the bullet point list of what will be in the class.
When I first read definitions like that, my initial reaction was, "OK....so what? How can that help me?" Quite a bit, as we're about to see over the next few nights.
I'm going to post three samples from the Common Ground Framework that I discussed in the July/August '05 issue of CoDe Magazine. For over a year, interfaces were an area of study and focus for me. In addition to all the textbook benefits of interfaces, they also carry some other practical benefits:
- They can reduce the need for reflection
- They help to get around the issue of multiple inheritance in C#
- They're valuable in distributed application development using remoting
The three examples that I'll cover are "real-world" situations:
- Many applications utilize data binding. Controls are bound differently (e.g. the code to bind a textbox is different from a checkbox, different than a combobox, etc.). The Common Ground Framework contains a data binding interface that not only reduces the amount of code to be written, but also abstracts the binding behavior to reusable classes that implement the binding interface.
- You're building a client Winform application that needs to communicate with a set of business objects. The Winform project/solution doesn't contain the business object DLLs, because they reside on the server. So you need to call methods in business objects that don't exist on the client domain. When you're using web services, you have the benefit of the web service proxy, which exposes the methods in the web service. However, in a remoting situation, we need to define our own "proxy".
The Common Ground Framework includes an example of interfaces and remoting that allow a developer to create an instance of a remote business object, cast it to an interface that defines the PEMs for the business object, and "discover" the PEMs through intellisense. - Many business applications have several "data maintenance" forms that allow the user to perform basic tasks: retrieving records that match a certain criteria, browsing/navigating through the results, editing records, adding records, etc. The tasks are usually common, though the lookup criteria and data for each form is very different. The Common Ground Framework contains a base form maintenance class and a series of interfaces to simplify the creation of data maintenance forms in such a way that the forms will have a consistent look and feel.
Stay tuned for Part 2, where we dive into the details!
Peace out...KG
Comments