[tody4me]

Not sure if this belongs in a more specific forum or not, but I'll ask here anyways. If this is more software development or something else, please move it there for me.

When creating a class, what determinations do you use as to make it a class or an interface? I currently have in my program made anything that is inherited an interface (due to C# limitations) and anything that is not a class. Back in my earlier days of programming though, I understood interfaces to be something different, mainly to be used in COM, as a way to define a class or how a class works.
So how do you guys use interfaces / classes when writing your programs?

This post has been edited by tody4me: 19 March 2008 - 08:24 AM

[Martyr2]

Well classes and interfaces can be drastically different things and the way you knew it through COM was pretty much the same as it is now I am sure. Think of interfaces as people wearing masks at a masquerade party. Some people might be caucasion, some may be black or asian... but in the context of the party they are all seen as guests with masks. Thus you could treat each guest the same without knowing anything behind the mask.

To make all classes that are inherited as interfaces is not going to be right and bad practice. Interfaces don't even have any executable code. They are just contracts that state that the class implementing the interface (the person behind the mask) will provide functionality defined by the interface (the person will act as a masquerade party guest with a mask and do guest actions). Even if behind the scenes they are completely different objects (the people behind the mask are of different races) they all know how to be a guest at the party.

So how would the situation work with classes with multiple interfaces? Again it would be like our masquerade party people agreeing to act as a guest, but also agreeing that they will also implement dancing as part of their abilities. Hence they have the masquerade guest interface and another for a dancing person. Hence each person, despite race will "be able to" act as a guest and be able to dance at the party guaranteed.

Hopefully that makes sense.

This post has been edited by Martyr2: 19 March 2008 - 10:40 AM

[tody4me]

Martyr2, on 19 Mar, 2008 - 12:38 PM, said:

Well classes and interfaces can be drastically different things and the way you knew it through COM was pretty much the same as it is now I am sure. Think of interfaces as people wearing masks at a masquerade party. Some people might be caucasion, some may be black or asian... but in the context of the party they are all seen as guests with masks. Thus you could treat each guest the same without knowing anything behind the mask.

To make all classes that are inherited as interfaces is not going to be right and bad practice. Interfaces don't even have any executable code. They are just contracts that state that the class implementing the interface (the person behind the mask) will provide functionality defined by the interface (the person will act as a masquerade party guest with a mask and do guest actions). Even if behind the scenes they are completely different objects (the people behind the mask are of different races) they all know how to be a guest at the party.

So how would the situation work with classes with multiple interfaces? Again it would be like our masquerade party people agreeing to act as a guest, but also agreeing that they will also implement dancing as part of their abilities. Hence they have the masquerade guest interface and another for a dancing person. Hence each person, despite race will "be able to" act as a guest and be able to dance at the party guaranteed.

Hopefully that makes sense.

And before I started to write code in C# that was how I understood it. However, in C# you can not inherit from multiple classes, but from multiple interfaces. Therefore to make my code work as I used to in C++, I had to make them all interfaces.

This post has been edited by tody4me: 19 March 2008 - 11:03 AM

[NickDMax]

yea... multiple inheritance is not generally a "well liked" technique and is generally not done outside of C++. In java/c# and a few other OO languages, to simulate multiple inheritance you have to either use interfaces, or build an inheritance hierarchy -- extend a class that extends a class etc.. If you really think about it though, this actually makes sense. inheritance defines a "is a" relationship -- how often do you have an object that "is a" widget and "is a" dohicky when a widget is not a dohicky and the dohicky is not a widget. It happens but more often then not this is just not really logical.

Though there are lots of people who think that this is a limitation of java/c#...

[Martyr2]

Ahhh I see, you used multiple inheritance that much in your c++ code? Rarely do I find the need to make such a setup and some will even argue that it is poor design, but I understand where you are coming from. Keep in mind though that you do have to define the functionality somewhere and that can only be done in the classes. So I look at it as build objects that make sense as classes, things that represent real life things and concepts, and if I need one of these classes to show some other behavior, then implement an interface for it.

It would be like having those screw drivers which have the changeable bits. Obviously the screwdriver is going to be my class and it will have all the functionality like twisting or if it is a power tool, maybe things like a light or whatever. Then when I need to put in or take out a phillips head screw, I will then construct the interface for my screw driver.

I guess to make my point short, always construct classes until you need one (or some) of your objects to exhibit some new behavior, then and only then construct the interface for it. Oh and take a look at your multiple inheritance situation and you probably will come up with an alternate relationship that will work either through encapsulation or delegation.

A ceramic mug might inherit from a cup object and a ceramic object... but typically you could get rid of the ceramic object and make it a property of the mug or create the ceramic object as your interface because it describes the mug more than what a mug actually is (it is a type of cup, that is what it is). It is saying that the mug is made of ceramic, not that the definition of a mug is that it is always ceramic.

But anyways, go with what makes sense the object is directly inherited from and use the other object as the interface.