Question of Interfaces

[Paul Kinlan]

Hi All,

I am quite curious about how people are using interfaces (as in the c# public interface IEye{}) .  So:

A Quick Couple Of Questions:

Do you do interface based development? How often do you create interfaces?

Do you like interfaces?  Do you prefer abstract classes?

When creating interfaces, do you have them in a separate project, or do you have them along side the base implementation of the interfaces?

Cheers,
Paul

[Thom Shannon]

i use them sometimes for plugin interfaces, i'll either put them in a separate assembly or have them in the business layer assembly so the plugin then has to have a reference to it.

i sometimes use them for data objects that have common uses but are derived from different types, like when you want to track ownership of certain entities which are otherwise completely different.

not sure if any of that is the "right" way to do things but it works for me.

--
*** OPEN COFFEE - http://upcoming.yahoo.com/event/833196/ ***

Terms & Conditions Apply: http://www.glow-internet.com/home/terms.aspx

Glow New Media
t: 0151 707 9770
m: 07730 987 574
www.glow-internet.com

Suite 712 Gostins Building
32-36 Hanover Street
Liverpool
L1 4LN

Map: http://tinyurl.com/2f5nxd

[Derek Fowler]

Do you do interface based development? How often do you create interfaces?

Yes and not that often, where-ever there's a well defined contract for some interaction, create an interface for it.

 

Do you like interfaces?  Do you prefer abstract classes?

What's not to like? They're conceptually different and used for different things.

 

When creating interfaces, do you have them in a separate project, or do you have them along side the base implementation of the interfaces?

I suppose you could put them anywhere but it makes sense to have them in the project that *uses* them i.e. not necessarily the project that implements them.

Derek

[Paul Kinlan]

Cool,

They both pretty much reflect my thoughts.

I just worry about where to place them, microsofts guidence recommends in seperate assemblies, however I don't know of any of their frameworks that do it this way.... So I am still in two minds.  I like the idea of basic implemenation next to the interface, obviously this means you can either subclass functionality or implement the interface with only one reference. 

There isn't too much difference between interfaces and abstract classes (apart from maybe multiple "inheritence"), its just awkward deciding between either... I ask the question about liking interfaces because I know lots of developers will never use intefaces and I am trying to find out why.

I use the "strategy pattern" quite a bit so interfaces are used a lot, but thinking about it, there really isn't any need and I could get away with an abstract class, I tend to put common functionality between all implemenations into an abstract class, so if that is the case when is there a need for an interface.

I suppose my other question (that I forgot to ask) is "marker interface" or attribute?

Paul

2008/8/12 Derek Fowler <dezf...@gmail.com>

[Derek Fowler]

so if that is the case when is there a need for an interface.

When you need to retrofit the ability to perform an interaction into an existing class. You can't feck with its inheritance, what you need is an interface. Or just when you don't want to use any of the base implementation code in your abstract class but still need to enforce some contract.

It depends on the problem you're trying to solve but if you work with an interface rather than a concrete class wherever possible it will make your code much more re-usable.

Derek

[Paul Kinlan]

The more that you use interfaces the more rigid your code becomes as you are less likely to be able to respond to changes without affecting all implementations at least with an abstract class you can mitigate some of that risk by including base/null functionality so that existing classes are broken.  So in a pluggable architecture maybe abstract classes are a better use than interfaces.

One of the only places where I can think that interfaces have a benefit over abstract classes for specification is when your class needs to be of more than one type, when retrofitting functionality is not just a case of composition.  I always wonder if the class has too be of two types if it indicates that a class is doing too many things and should be simplified.

Just thought it would be interesting to get a conversation going. :)

Paul.

2008/8/13 Derek Fowler <dezf...@gmail.com>

[Ryan Tomlinson]

Do you do interface based development?

It isn’t a case of “doing interface development”. Interfaces are used to define contracts between objects where the interface defines common behaviour. For example given the example of an interface that defines whether an animal can run or not. We may have an interface defined as IRunnable which has methods Walk, Run and Sprint. If we were then to create a dog object we would ensure that this object implemented the IRunnable interface. We may also have cheetah, puma and tiger objects which all again should implement the IRunnable interface and we may also have some other objects that wouldn’t implement this interface, such as a fish or whale object. Not only does the IRunnable interface define a contract that makes semantic sense but we can also use techniques such as reflection to find all those animals that can run, in which case we search for those objects that implement the IRunnable interface.

 

This is perhaps a long winded, exhaustive and boring example J but I hope that it highlights that it shouldn’t be a case of whether you do use them but you should use them when they are required to give you a concrete design.

 

How often do you create interfaces?

Again you should use interfaces as an when they are required.

 

Do you like interfaces? 

Of course, they are greatly useful and should be designed into your objects when it makes sense to do so.

 

Do you prefer abstract classes?

Abstract classes and interfaces should not be confused and you should be clear as to not only what the differences are but why they are used and when. Whenever concrete implementation is required across multiple objects you should use abstract classes, but when only behavioural similarities are required but their implementation is different we should use interfaces. As cliché as it sounds its horses for courses.

 

When creating interfaces, do you have them in a separate project, or do you have them along side the base implementation of the interfaces?

Where the interface resides is not a big issue to me. Although they should be structured in the correct namespaces.

 

I hope this has helped you a little. If you are new to .net and/or development in general you should take a look at the asp.net starter kits on the asp.net site. You can download these projects and take time to digest them, the way they are architected and how they use both interfaces and abstract classes. I would then suggest looking into frameworks such as CSLA and download their example project. These should all help clarify interfaces.

 

Kind regards,

 

Ryan Tomlinson

No virus found in this incoming message.
Checked by AVG.
Version: 7.5.524 / Virus Database: 270.6.0/1603 - Release Date: 10/08/2008 18:13

No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.524 / Virus Database: 270.6.1/1608 - Release Date: 12/08/2008 16:59

[Paul Kinlan]

Hi Ryan/All,

I am quite interested in this to find out how people are using interfaces, not so much "I don't understand interfaces".  I use interfaces to specify what I believe to be a contract between systems, sub-systems and also implementations of strategies etc, however in the majority of cases where I create an interface I tend to create an abstract class that implements the interface and all subsequent implementations are then subclassed of this abstract class, so my argument there is, is there much point at all in defining the interface in the first place.  Its hard to ask formulate the question, but I have put in some of my thoughts below.

Interfaces are used to define contracts between objects where the interface defines common behaviour

There is nothing in an interface that defines a contract that an abstract class doesn't do.  I have found it harder to version my applications with interfaces because I am more likely to break the clients of the interface. 

Not only does the IRunnable interface define a contract that makes semantic sense but we can also use techniques such as reflection to find all those animals that can run, in which case we search for those objects that implement the IRunnable interface.

Again, there is nothing there that cannot be achieved with abstract classes.

I sometimes think that the only place interfaces have a benefit over abstract classes is when you want to simulate multiple inheritance.  But even that goes against a principle that I have been trying to stick to recently which is keep each class responsible for only one thing.

I hope this has helped you a little. If you are new to .net and/or development in general you should take a look at the asp.net starter kits on the asp.net site. You can download these projects and take time to digest them, the way they are architected and how they use both interfaces and abstract classes. I would then suggest looking into frameworks such as CSLA and download their example project. These should all help clarify interfaces.

I would suggest that once people have looked at these, read Framework Design Guidelines, because its best advice contradicts most of the "accepted" use of interfaces.  Another link is here http://msdn.microsoft.com/en-us/library/ms229013.aspx and http://www.theserverside.net/tt/articles/content/FrameworkDesign/Chapter4.pdf (page 80 ish)

Some of the comments of the .Net architects are as follow: (this is based around designing for frameworks, but I think it applies to "normal" application development)

KRZYSZTOF CWALINA I often hear people saying that interfaces specify
contracts. I believe this is a dangerous myth. Interfaces, by themselves,
do not specify much beyond the syntax required to use an object. The interface-
as-contract myth causes people to do the wrong thing when trying to
separate contracts from implementation, which is a great engineering practice.
Interfaces separate syntax from implementation, which is not that useful,
and the myth provides a false sense of doing the right engineering. In
reality, the contract is semantics, and these can actually be nicely expressed
with some implementation.

KRZYSZTOF CWALINA Over the course of the three versions of the
.NET Framework, I have talked about this guideline with quite a few developers
on our team. Many of them, including those who initially disagreed
with the guideline, have said that they regret having shipped some API as
an interface. I have not heard of even one case in which somebody regretted
that they shipped a class.

JEFFREY RICHTER I agree with Krzysztof in general. However, you do
need to think about some other things. There are some special base classes,
such as MarshalByRefObject. If your library type provides an abstract
base class that isn't itself derived from MarshalByRefObject, then types
that derive from your abstract base class cannot live in a different AppDomain.
My recommendation to people is this: Define an interface first and
then define an abstract base class that implements the interface. Use the
interface to communicate to the object and let end-user developers decide
for themselves whether they can just define their own type based on your
abstract base class (for convenience) or define their own type based on
whatever base class they desire and implement the interface (for flexibility).
A good example of this is the IComponent interface and the Component
base class that implements IComponent.

CHRIS ANDERSON Here is one instance in which the design guideline,
if followed too strictly, can paint you into a corner. Abstract types do
version much better, and allow for future extensibility, but they also burn
your one and only one base type. Interfaces are appropriate when you are
really defining a contract between two objects that is invariant over time.
Abstract base types are better for defining a common base for a family of
types. When we did .NET there was somewhat of a backlash against the
complexity and strictness of COM—interfaces, Guids, variants, and IDL,
were all seen as bad things. I believe today that we have a more balanced
view of this. All of these COMisms have their place, and in fact you can see
interfaces coming back as a core concept in Indigo.

BRIAN PEPIN One thing I've started doing is to actually bake as much
contract into my abstract class as possible. For example, I might want to
have four overloads to a method where each overload offers an increasingly
complex set of parameters. The best way to do this is to provide a nonvirtual
implementation of these methods on the abstract class, and have the
implementations all route to a protected abstract method that provides the
actual implementation. By doing this, you can write all the boring argument-
checking logic once. Developers who want to implement your class
will thank you.

Abstract classes and interfaces should not be confused and you should be clear as to not only what the differences are but why they are used and when. Whenever concrete implementation is required across multiple objects you should use abstract classes, but when only behavioural similarities are required but their implementation is different we should use interfaces.

You don't need any implementation in an abstract class, so maybe don't consider the differences of either abstract or interface, but the limitations of both.  I personally don't think the arguments that most people give actually represent the fact.  In nearly all cases I can't think of a reason to use interfaces over abstract classes, unless I want to use multiple inheritence.

Paul

2008/8/13 Ryan Tomlinson <tomlin...@gmail.com>

[Ryan Tomlinson]

An abstract class indeed does not need an implementation. If you want to "simulate multiple inheritance" and are having these problems, I would consider your design. It is difficult for me to say without knowing what exactly you are trying to acheive. An interface is used to define common behaviour between classes which otherwise have no relationship to each other. For example an Image and a Document might implement the IPrintable interface but their implementation would be completely different and therefore we would create a IPrintable interface to define the contract of behaviour. I hear what you are saying about an abstract class could define what this interface does but an abstract class is semantically incorrect here as an abstract class implies an "is-a" relationship. Which is completely in appropriate in this example.

Ryan

[Thom Shannon]

Going a bit further with that example, you may have an image object and a video object, both may be printable (video prints as frames), but the video is derived from a multimedia class, which isn't printable (it could represent audio). So the IPrintable is a piece of functionality that is supported by two objects that aren't closely related and don't share that functionality with a common ancestor.

[Paul Kinlan]

I am only trying to achieve a discussion.

The point of multiple inheritance was only that, I am not having any problems with anything. An interface doesn't define a contract of behaviour, it describes at best describes a "can-do"/supports which in may only be good for supporting one operation, so in the IPrintable scenario, the only method it should have is a Print().  This is where the "multiple inheritance" point was supposed to go but I completely missed it in my previous email; I could then say my object also supports compression via IComrpressable.Compress().  On an aside: from a design point of view, you might argue that having a document print itself is a bit too much reponsibility, so you would have a DocumentPrinter/ImagePrinter/xyzPrinter that takes documents and images and know how to print them.

I just think that in the majority of cases, interfaces are overused and I was trying to see if how people use them and if people are in the same mind as me (or what their mind is).  In most cases I question if interfaces are really the correct choice.

Paul.

2008/8/13 Ryan Tomlinson <tomlin...@gmail.com>