[RESOLVED] [2008] When/Why would you use abstraction and Interfaces

[chris128]

Hi Guys,

I'm just reading up on Abstract classes and Interfaces and although I believe I am now familiar with the concept, I am struggling to see how or why I would ever use them. Now I know that existing objects in the .NET framework already use both of these models, like Lists implementing IEnumerable etc. Thats all well and good but if I wanted something that was 'enumerable' I would just stick it in a List or Array instead of creating my own class that implemented IEnumerable. So yeah, can anyone give me some examples of when you have needed to create your own classes that either use MustInherit to create an abstract class or when you have had to create your own class that implements an interface. Also, perhaps some examples of why/when you have created your own interfaces?

Thanks
Chris

[jmcilhinney]

A classic example of when you need to use an interface is when creating a plugin architecture. You create an application with the intention of other developers extending it, but you can't let them just do whatever they like. You have to impose some rules and structure on what they can do an how they can do it. This is almost always done using an interface.

You define an IPlugin interface that provides whatever methods and properties you deem appropriate for your app. It's then up to each developer who wants to extend your application to define their own class that implements that interface. At run time, your app will query a folder for DLLs and interrogate each one to find a class that implements your IPlugin interface. It knows exactly what members it can access because the interface defines them, but how each plugin implements those members is completely up to the author of that plugin.

When I'm explaining interfaces I usually use USB as an example. USB is an interface. It defines a set of functionality that a device must implement to be called a USB device. There are literally thousands or even millions of different USB devices available. Their functions are many and varied, yet your computer can communicate with each of them because each of them implements the USB interface. Programming interfaces are exactly the same, just not quite as tangible.

As for abstract classes, I'm working on an example right now. I'm working on an application that manages insurance policy and claim data, which gets input from Excel spreadsheets. The data gets read from the XLS file into a DataTable, using ADO.NET, and then validated for correctness and completeness. The policy data and claim data are read from different files and, while the data has similarities, it also has differences.

I created a TableValidator class that contains the common functionality. It defines various concrete members whose functionality is the same for both policies and claims. It also defines several abstract members, which will be required for both policies and claims but must be implemented differently for each. For instance, there's a property that returns a string array containing the column header text. This is declared abstract (the code is C#, equivalent to MustOverride in VB) in the TableValidator class. In the PolicyTableValidator and ClaimTableValidator classes, which each inherit TableValidator, this property is overridden and a concrete implementation provided.

In the TableValidator class there is a concrete ValidateColumnNames method. This method gets the value of the ColumnNames property, which is abstract. The actual value depends on the actual type of the current object. Note that, because TableValidator contains abstract (MustOverride) members, the class itself is declared abstract (MustInherit).

[chris128]

Thanks, I think I understand the Interfaces side of things a bit better now and I can see where they would come in handy.

As for abstract classes though, can you just confirm that this is right?
You are basically using your abstract TableValidator class sort of as a template to base two other classes on. In your abstract 'base' class you define some hard coded methods that do exactly the same thing in each of the two inherited classes. For example, say you had a function that just returned the name of the Excel file or something, this would be a concrete member defined only in the abstract class (TableValidator) yes?
Then for methods where you need to actually do something different based on whether or not the item is a Policy or a Claim, you set the methods in the abstract class to MustOverride (in vb terms) and in each of the classes that inherit from the abstract class you can create totally separate routines that do different things yeah?

Please correct any of that if its wrong or if I have used the wrong terminology

So what is the benefit of declaring these MustOverrride members in the base class as opposed to just inheriting the concrete members from the base class and then adding new members to it in the inherited class? Is it just so that you know what methods and properties to expect from the classes that inherit the abstract class (in a similar way to how you would use interfaces so that you knew what type of data a method would return) ?

Thanks again

[jmcilhinney]

As for abstract classes though, can you just confirm that this is right?
You are basically using your abstract TableValidator class sort of as a template to base two other classes on. In your abstract 'base' class you define some hard coded methods that do exactly the same thing in each of the two inherited classes. For example, say you had a function that just returned the name of the Excel file or something, this would be a concrete member defined only in the abstract class (TableValidator) yes?
Then for methods where you need to actually do something different based on whether or not the item is a Policy or a Claim, you set the methods in the abstract class to MustOverride (in vb terms) and in each of the classes that inherit from the abstract class you can create totally separate routines that do different things yeah?

That is correct.

So what is the benefit of declaring these MustOverrride members in the base class as opposed to just inheriting the concrete members from the base class and then adding new members to it in the inherited class? Is it just so that you know what methods and properties to expect from the classes that inherit the abstract class (in a similar way to how you would use interfaces so that you knew what type of data a method would return) ?

Here's a simplification of what I'm doing:

Public MustInherit Class TableValidator
 
    Public MustOverride ReadOnly Property ColumnNames() As String()
 
    Public Sub ValidateDateColumns()
        For Each columnName As String In Me.ColumnNames
            'Do something.
        Next
    End Sub
 
End Class
 
 
Public Class PolicyTableValidator
    Inherits TableValidator
 
    Public Overrides ReadOnly Property ColumnNames() As String()
        Get
            Return New String() {"InsurerName", "PolicyNumber"}
        End Get
    End Property
 
End Class
 
 
Public Class ClaimTableValidator
    Inherits TableValidator
 
    Public Overrides ReadOnly Property ColumnNames() As String()
        Get
            Return New String() {"PolicyNumber", "ClaimNumber"}
        End Get
    End Property
 
End Class

You see that the ValidateColumnNames method is implemented in the abstract base class because it is exactly the same for both policies and claims. It refers directly to the ColumnNames property, which it can do because that property is declared in the base class, even though it's not implemented. Each derived class provides its own implementation, which is what actually gets invoked at run time.

If the ColumnNames property was not declared in the TableValidator class then the ValidateColumnNames method couldn't refer to it because it wouldn't actually exist at that level. As it is, the ColumnNames properties of both the PolicyTableValidator and ClaimTableValidator classes are different implementations of the same property, so they can be treated as the same property. If those classes simply declared their own properties without inheriting ColumnNames from TableValidator, they would actually be two different properties. The fact that they had the same name would be simple coincidence and they could not be treated as the same entity.

[chris128]

Ah ok I get it now thanks for the examples and information