Sign in to follow this  
dingojohn

Interface, base class or just a plain class

Recommended Posts

dingojohn    159
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.

Share this post


Link to post
Share on other sites
Telastyn    3777
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).

Share this post


Link to post
Share on other sites
Structural    328
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.

Share this post


Link to post
Share on other sites
ToohrVyk    1595
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this