Jump to content
  • Advertisement
Sign in to follow this  
LordShade

[.net] Interfaces, interfaces, interfaces

This topic is 3804 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've been a C++ guy since forever but I've taken the plunge into C# and I'm liking it. Back when I first started writing OO games I'd make derived classes and more derived classes. As you can imagine, the heirarchy trees would get pretty deep. Then along comes COM. I used this for many years in my "job" but during that time I couldn't bring myself to work on game dev in my off hours. I'm sure some of ya know what I mean. Although, during that time, I was beginning to see the power that interface programming could bring to game programming. So I haven't done professional programming for several years now, burnt out, but I'm dipping back into the pool with C#. Recently I have discovered how truly effective interface architecture can be. It's late and I'm rambling. If you find yourself having massively deep heirarchy trees, do yourself a favor and try working in interfaces. You'll be surprised how elegant and yet simple your code becomes. In C#, interfaces are a snap. Granted, I still have a few 'core' classes I'll derive from to inherit functionality but interfaces are superb for things like Physics and Collision/Response. Nothing like coding a whole new object and dropping it into the "universe" and having things just go. :) Happy coding.

Share this post


Link to post
Share on other sites
Advertisement
Interfaces can do some rather crazy things that you wouldn't think would be allowed:


public interface IControlPeerGroup
{
void Add(Control control);
IEnumerable<Control> Peers { get; }
}

public class ControlPeerGroup : List<Control>, IControlPeerGroup
{
public IEnumerable<Control> Peers
{
get
{
foreach (Control control in this)
yield return control;
}
}
}


Notice the IControlPeerGroup interface has an "Add" method that I haven't explicitly implemented in ControlPeerGroup? Somehow, it knows to check the BASE class (List<Control>) for the interface implementation as well. And it works, which is even more scary.

Share this post


Link to post
Share on other sites
I personally like using interfaces and have an abstract implementation class of the interface(or one class that implements multiple interfaces) to help when writing a class that need to expose the interface. That way I don't have to re implement the same interface but if a situation arises where I need to do it differently or whatever, I still have the flexibility. Besides, I think it's cleaner to have other parts of the application only use interfaces it needs and not be tied to a particular base class. Microsoft's XNA 2.0 does things like this as well.

Share this post


Link to post
Share on other sites
Deep inheritance hierarchies are bad mmmkay. Interfaces are good, but little things seem to keep them from being as useful as they should be. Delegate types can't be declared, and they're not duck typed when most of their usage is "give me a type that matches these capabilities."

I find myself using standard abstract base classes more often.

Share this post


Link to post
Share on other sites
I like inheritance and interface combinations. I use inheritance to break up proceedures. ie: I have a base class Initializer that is base for Processor that is base for Renderer. Each class keeps the code seperate from eachother and easier to view and work on. Then I create interfaces so that other, out of assembly (and in assembly) systems can access specific need portions of the object.

I guess I use interfaces like a panel that interfaces a machine and gives access to a specific portion of the machines operation and workings.

And I use inheritance as building blocks for the individual parts of the machine so that it can be broken up into major parts or portions.

I'm a big lover of c#. I used c++ for much of my younger years but can't take my mind off of c#. It's just brilliant. A super language I think. As long as it exposes ways of having the c++ abilities then it can simply replace it all together in my opinion.

But I'm not very learned in c++ and I'm sure others would say otherwise and probably be right.

-Devin

Share this post


Link to post
Share on other sites
Quote:
Original post by Telastyn
Deep inheritance hierarchies are bad mmmkay. Interfaces are good, but little things seem to keep them from being as useful as they should be. Delegate types can't be declared, and they're not duck typed when most of their usage is "give me a type that matches these capabilities."

I find myself using standard abstract base classes more often.


Hmm, I'm not sure I understand this comment. An interface is just an agreement that any object with that interface will support those method calls. You can't define a type in an interface because it is a pure abstract type.

Granted, I still do use inheritance in alot of cases when I need a particular type of functionality and don't want to re-implement it.

ATM, I'm struggling with figuring out how to create an instance of a type if all I know is a string representation of it's name(i.e., Package.Folder.TypeName) and it's module. hehe.

[Edited by - LordShade on April 19, 2008 11:19:07 AM]

Share this post


Link to post
Share on other sites
I want an interface to have an event that takes a string and returns a string.


public interface foo{
delegate string DelegateType(string parameter);
event DelegateType fooEvent;





oops, error. The Func<T> stuff makes that easier but is 3.0 only, and it requires that the delegate specifically match the type, not just the signature.

Plus these don't work:


public interface SomethingWithAName{
string Name;
};

public class Joe{
public string Name = "Joe";
}

public class Bob{
public string Name{
get{
return("Bob");
}
set{}
}
}

SomethingWithAName Someone;

Someone = new Joe();
Someone = new Bob();





And they should. Even if the interface.Name was a property, you can't assign Bob to it since it doesn't explicitly inherit from the interface. This is (imo) very detrimental to their usage.


Quote:

ATM, I'm struggling with figuring out how to create an instance of a type if all I know is a string representation of it's name(i.e., Package.Folder.TypeName) and it's module. hehe.


System.Reflection.ModuleInfo and System.Activator

Though umm... icky.

Share this post


Link to post
Share on other sites
You cannot declare a delegate inside of an interface, but there is no reason you cannot declare it outside of the interface:


public delegate string DelegateType(string parameter);
public interface foo{
event DelegateType fooEvent;
}


the only difference is the external naming of the delegate. (DelegateType vs. foo.DelegateType)

You cannot declare fields in an interface, but there is no reason that you cannot declare properties:

public interface SomethingWithAName{
string Name{get;set;}
};


Fields themselves are an implementation detail and do not belong in an interface.

With C# 3 you can also make extension methods that apply to interfaces, something that may seem trivial, but it can be used to patch some of the holes that the lack of multiple inheritance left in the language.

Share this post


Link to post
Share on other sites
I'm with Telastyn. I only use interfaces when I'm absolutely certain it's something that's going to be multiply inherited. Otherwise I prefer the greater power of abstract classes.

For example, whenever possible I like to use the abstract class to enforce consistent behavior in different implementations. For example the abstract base class may check that a methods arguments are valid, rather than assuming different implementations will do so.

Share this post


Link to post
Share on other sites
Interfaces are nice. They remind me of Haskell type classes. Not watered down but with a different focus that makes them more flexible for traditional OOP programming but less flexible in terms of typeful programming.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!