Back to General and Gameplay Programming

Interface, base class or just a plain class

General and Gameplay Programming Programming

Started by dingojohn November 21, 2007 06:08 AM

2 comments, last by ToohrVyk 16 years, 4 months ago

dingojohn

159

Author

November 21, 2007 06:08 AM

Quote:Original post by GoF Program to an interface, not an implementation.

Right. I will. However, is that always what you want? I have a renderer. It can render a surface at a given position. A surface contains a texture/shader and geometry data including normals. Now, if it was to code to an interface, i'd do something like

RenderDevice.Draw(ISurface surface)
    {

        // get geometry and shader from the surface interface
        // do something with it. Note that this is C# but it does not really matter.
        surface.Geometry;
        surface.Shader;          
    }

Would that be a good idea, or should I just create a surface class and use that, since I believe that it wont change much. Also, should the Geometry in a surface be an interface that can return vertices, normals, textureCoordinates, indices etc, or should it just be a normal class that will be used for all surfaces? I'm really trying to think in interfaces to rely on that instead of the underlying mechanics. However, I seem to struggle here. I know that it works fine both ways, but what is to prefer? If it does not matter, then I guess the added overhead of interfaces makes that less of a choice. Well, I'd love input here. Thanks in advance.

Telastyn

3,778

November 21, 2007 08:27 AM

Enh, whatever. Such things are implementation details which will vary depending on what your language provides, and the scenario. Which would be the most flexible, readable, easy?

As long as you code to the concept of an interface you should be fine. Personally, I prefer (usually abstract) classes as interfaces in C# unless I'm specifically making something for multiple inheritance (which is a code-smell that a class is too large/doing too much, but sometimes useful).

-- Tangent Developer Journal - Delegates - Part 2

Structural

328

November 22, 2007 01:09 AM

If you don't need an abstraction, don't create an abstraction. If you only have one implementation of a surface, don't bother with an interface.

If you need an interface in the future then one is extracted in a matter of a few minutes. For now, it's just bloat and makes your hierarchy more complex than it needs to be.

STOP THE PLANET!! I WANT TO GET OFF!!

ToohrVyk

1,596

November 22, 2007 01:30 AM

Quote:Original post by dingojohn
Quote:Original post by GoF
Program to an interface, not an implementation.

Right. I will.

Now, if it was to code to an interface, i'd do something like

You're misinterpreting the GoF book. When they explain that you should program to an interface, they do not mean that you should create an "interface type in the UML sense" and then derive your class from it. That would be pretty pointless in cases where abstraction isn't needed or even welcome.

They mean that you should first decide on the "interface in the class/function signature sense" of your class, which describes how it will be used, and only then concern itself with how it will work. That is, first write a few quick prototypes of how the class is going to be used: typical construction pattern, typical use cases with usage patterns, interaction with standard library constructs or other constructs from within your code, and so on. Once you've settled on a clean set of public members for your object, you can decide what its private members are (both data and methods) and implement the public methods (which until then were merely throwing stubs) in terms of those private members.

Blog — Facebook

Interface, base class or just a plain class

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Interface, base class or just a plain class

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines