Where do you use Interfaces. 1

[GARooke]

There was an interesting discussion below about what the benefits of interfaces are. I can see all of those, and the answers were very helpful to me.

However, I'm not sure where they should be used.
Do you need an interface, between every class? I dont like that thought but I could be wrong. Why not?
Do you divide the classes into tiers and put interfaces between every tier?
If you divide the toers 'vertically' into components, services or whatever, is that where interfaces should go?
Do you only put them in where you see potential benefits as listed in the other discussion?

Gil

 

[DonQuichote]

What language are you programming in? Interfaces are, by definition, totally abstract classes, but unfortunately not all languages grasp this.

In visual basic (up to 6.0), for instance, there is no such thing as an abstract class, so you'll have to make a (dummy) concrete class. In fact, the

implements

keyword accepts any concrete class to get the interface from.
This makes the use of separate interfaces somewhat limited, as you can always implement the interface of another class.
Also, VB (even dot net) has a "wolf in sheeps clothing" kind of interface implementation. The same object can have a totally different set of methods (whithout any overlap) by calling it another data type. So in VB it is not, as in most languages, a partial contract.

I heared that in Java you can define variables in interfaces and that this fact is often abused to define class constants.

 

[GARooke]

I'm looking at general design, largely for java and possibly C++. These do have abstract classes because they are more OO.

Why is defining static variables an abuse?

Gil

 

[DonQuichote]

Variables are an implementation, not an interface. Well public variables are both, off course.
The main problem with it is that they are often used for enumeration-like purposes. Those constants are magic numbers, rather than enumerations. If you make the enumeration members share their own type (say "SomeEnumeration" instead of "integer&quot, you have the compiler checking your code at every compilation. Sun has a nice tutorial on this somewhere, but I can't find it on their site.

Best regards

 

[DonQuichote]

Looking back to the original post, I'd say that you would only "need" a compatibility-interface for exposed classes.

I'm not sure if you really need them, however. I think it all depends on the language being capable to see the compatibility between a concrete class and an abstract one. Maybe I must clear myself here. If, say, in version 1.0 of a library you have a concrete class, you could make the same class abstract in version 1.1. The only thing you'd have to do is change the factory method that generates the instances of the class and provide a concrete class that inherits from the now abstract class.

If this is possible, the original class is now fully abstract and therefore an interface.

I believe interfaces were introduced in languages like Java to omit multiple inheritance. So if you really need something like that, you'd have to do it with interfaces.

Best regards

 

[Polu]

Hello, GARooke & DonQuichote.

Here are some situations where interfacing will be very useful:

1. Packages are/will be developed by differents teams, maybe very far one from another in time and/or space

2. Packages designed to be used for a large community of developers

3. Packages designed to evolve in time through a number of different versions (For example in a large scale project divided in many phases)

4. In a N-layers architecture, where every layer could be replaced at everytime (just like OSI)

5. In a pipelined architecture

In a more general view, you must use interfaces when you think that something could change in future versions and/or in different instances of your system and you want to prevent these changes to become out of control.

Well, that's all. I hope it will be useful.

Best Regards.

Polu. Nacho Vargas.
Consultant.
D.M.R. Consulting (a Fujitsu Company)

http://www.spain.dmr.com

 

[PatHill]

Interfaces are often used for "plug-in's" where the host program doesn't need to know about the implementation, just that a particular object will support particular method signatures.

Interfaces are the foundation of COM (that's just a statement, not a recommendation) - so if you do any COM programming, you'll soon appreciate what interfaces are all about!

Abstract Classes are not the same as Interfaces, because an Abstract class can contain implementation code , whereas an Interface cannot - its purely a list of method signatures.