Interfaces and Patterns 3

[golcarlad]

It seems that interfaces are mainly useful in a design pattern that adopts the Decorator principle (i.e. inheriting objects much the same way abstract classes work) - is this true? if not what other advantages or uses has an interface in allowing you to write more efficient and elegant code?

 

[JurkMonkey]

The plug-in pattern also.

It just defines a generic way for a class to interact with another class without having to know the exact class type.

 

[stevexff]

Interfaces also allow you to simulate multiple inheritance in C#.

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object:erlDesignPatterns)[/small]

 

[GeertVerhoeven]

Hi,

Suppose you have an application that has two types of people: Customer and Employee. Both Customer and Employee can subscribe to an event. The procedure of subscribing is different. Customers need to pay and subscbribe where as Employees only need to subscribe.

When you have a list of objects (both Customers and Employees) that want to subscribe, you need to check for each object what type of person it is before knowing how it needs to subscribe to the event. If at a certain point you add a different person type, you need to add additional code in the calling class.

With interfaces this can be a lot easier. First we create an interface named IPerson. This interface has a method named Subscribe. Than we make sure that all the person types implement this interface. The method Subscribe is implemented in the classes (Customer, Employee).

If we need to have a list of persons we create the list as follow:
List<IPerson> myList = new List<IPerson>();

IPerson person1 = new Customer();
myList.Add(person1);

IPerson person2 = new Employee();
myList.Add(person2);

Now when we loop through the list, we can use IPerson.Subscribe() to subscribe a person. This will cause the .NET framework to call the Subscribe method from the objects class.

Interfaces make it easier to extend this type of code. When a different person type is needed, you only need to add a class that implements the IPerson interface.

Let me know if the above is not clear.

Greetz,

Geert



Geert Verhoeven
Consultant @ Ausy Belgium

My Personal Blog

 

[cappmgr]

So far I have only seen the pro's of using an interface in this thread. Here is a con, if I modify an interface then I have to modify every class that implements the interface.
Interfaces and abstract classes are different knowing when to use one versus the other is what matters.

http://msdn.microsoft.com/library/d...html/vbconabstractclassesversusinterfaces.asp

Marty

 

[IT4EVR]

Nice blog Geert..and nice example.

Interfaces are often discussed in hushed tones. Very few programmers use them and even fewer understand how to implement them properly.

 

[cappmgr]

Geert,
A very nice post, I would like to offer some constructive criticism. You used Subscribe as a method and Event (a reserved word) as a property. "Both Customer and Employee can subscribe to an event." It reads as though the post is about delegates and events.

In your example you used Customer and Employee, both of which can subscribe to the same Event. This is a commonality and would suggest an abstract class is a better option than an interface to enforce the contract. The abstract class would have a method that retrieves the Event's name, date, time, location, and other information. The abstract class would also have an abstract Subscribe method for subscribing to an Event. The default implementation of the Subscribe method would be for a Customer. We hope to have a lot more customers than we do employees.
Customer and Employee would then inherit from the abstract class. The Employee class would then override the Subscribe method, and implement it's own so employees do not have to pay. If the data source changes for the Event's it is changed in one place the abstract class and does not break our subclasses.

An example of an interface could be IMovable with a Move method. A class Human and a class Car could implement the IMovable interface. Since Car and Human are disparate each would have their own implementation of Move.

Marty

 

[stevexff]

Very few programmers use them and even fewer understand how to implement them properly.

I've often found the reverse, where they think it's a good idea for every class to implement an interface, "just in case we need the flexibility later on", or "because our architecture standards say we should".

Interfaces allow multiple inheritance, but only specify the method names and signatures, not the implementations. Each implementing class must supply these themselves.

Abstract classes allow methods to be inherited, but only support single inheritance and can't be instanciated directly.

One isn't inherently better than the other. Choose the one that most closely matches your needs for the job in hand. If you don't need either, don't use them at all...

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object:erlDesignPatterns)[/small]