OOP: C# Interface Details

This post is based on chapter 9 of Andrew Troelsen’s “Pro C# 2008 and the .Net Platform” available from Apress.

So we covered the basics of these in the previous post, let’s look at some more details about these.

In the example in the previous post note that the interface is public – this of course makes a lot of sense, but what about the method signatures – these have no access modifiers and no implementation… the reason is of course that interface members are implicitly public and abstract – however it is a syntax error to actually apply either of these to the members.

So when implementing, as in previous example, you use the : operator. If you are inheriting from another class this must be listed first, and then you can list as many comma seperated interfaces as you like. Note that you should always name your interfaces with a leading capital I – no requirement, but your fellow OO coders will spank you into infinity if you do not. And don’t think you can get free spanking like this – they will notice if you like it and think of something else, like putting tuna in your keyboard. Dophin friendly of course.

So, one of the happy things about interfaces is of course that they (like abstract classes) can be used polymorphically. If/when you do this, always cast with the as operator and then null check the result – more here:  http://msdn.microsoft.com/en-us/library/cscsdfbt.aspx or you can use the is operator and then perform your cast if true: http://msdn.microsoft.com/en-us/library/scekt9xw.aspx.
Which is best? Well I personally like the as – as this not only checks but does half the job for you – I’ve not been able to dig out anything on performance, but at a guess the as operator covers over a try/catch like structure, where as the is would probably use seome lightweight reflection – so use as.

Following on from the above, also consider using interface types as methods parameters, this will allow you to write clean generic code that focuses on general (extendable) behaviours rather than specific implementations. So forexample we could pass any FridayNightReveller into a method accepting an IEnjoyADrink interface type – and work with this without concerning ourselves with the specific implementation – and what’s more important, we can easily extend the list of behaviours (i.e. the group of classes implementing the behavious defined by the interface) without changing any other code (Strategy Pattern).

Within VS2008 you also have some advanced options when working with interfaces. First of the refactoring meny allows you to extract and interface from a block of selected code – so you might have one behaviour and need another similar.
Also you can use the automatic options after typing the : operator followed by an interface name to automaticall implement an interface (you get a stub).

In some rare circumstances you might have a class implementing >1 interface and end up with a name clash (so e.g. two interfaces with a PerformCalculation() metod – in this case you can implement each method prefixed with the interface type so: InterfaceOne.PerformCalculation() and InterfaceTwo.PerformCalculation()
This is known as Explicit Interface Implementation – likely you’ll never use it.

Note that you can build interface hierachies – where one interface implements from another. An interface will of course never implement the parents methods, but simply extend (i.e. add to) the defined members. Note that multiple interface extension is allowed – so your interface can of course extend >1 other interfaces!

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: