C# – Declaring Interface in the Same File as Base Class: Good Practice?

A couple of thoughts:

1. It's better if game components don't know how to draw themselves. A class should have only one reason to change; here your components may change if you need to change what they do in-game, and they could change if you need to change how they're drawn as well.

2. For this scenario the most straightforward solution is use instanceof. It's not the most general solution but it's the simplest thing that'll solve this particular problem.

   for (GameComponent component : gameComponents) {
       if (component instanceof Drawable) {
           ((Drawable) component).draw();
       }
       if (component instanceof Updatable) {
           ((Updatable) component).update();
       }
   }
   

3. If you have a finite set of GameComponent types, what you want is a sum type, which mainstream OOP languages don't provide native support for but you can kind of emulate through the Visitor Pattern. (There's an alternative way of implementing them but it won't be elegant in Java; it works best with named arguments and lambda expressions.) This is a more general solution to taking decisions based on the particular kind of GameComponent because it gives you full access to the component type.

It would look something like this:

    public interface ComponentVisitor {
         void visit(Foo foo);
         void visit(Bar bar);
         void visit(Baz baz);
    }

    public abstract class GameComponent {
        // prevent subclassing outside this scope
        private GameComponent() {}

        public abstract void accept(ComponentVisitor visitor);

        public static final class Foo extends GameComponent implements Drawable, Updatable {
            // implement ...

            public void accept(Componentvisitor visitor) {
                visitor.visit(this);
            }
        }

        public static final class Bar extends GameComponent implements Updatable {
            // implement ...

            public void accept(Componentvisitor visitor) {
                visitor.visit(this);
            }
        }

        public static final class Baz extends GameComponent {
            // implement ...

            public void accept(Componentvisitor visitor) {
                visitor.visit(this);
            }
        }
    }

Now you can take component-specific decisions like this:

    for (GameComponent component : gameComponents) {
        component.accept(new ComponentVisitor() {
            public void visit(Foo foo) {
                // do something Foo-specific here
            }

            public void visit(Bar bar) {
                // do something Bar-specific here
            }

            public void visit(Baz baz) {
                // do something Baz-specific here
            }
        });
    }

This works because any component needs to implement accept, and for visit(this) to compile the Visitor needs to have a method that accepts that particular kind of component. It's still possible to implement a component such that accept doesn't call visit(this), so we safeguard against that by using a private constructor. That prevents outside subclassing while allowing subclassing of inner classes (because inner classes have access to private members of their enclosing class.) The end result is a finite set of components and an exhaustive way to discriminate between them (you can't forget to handle one of them because the Visitor implementation wouldn't compile.)

I doubt that an interface like IPoint3D brings you more benefits than trouble, so here my suggestion: create a concrete, immutable (so also sealed) class Point3D instead. When using interfaces, the geometric point/vector operations can only be implemented in a fashion where the underlying type information gets lost, but that is not a problem of the programming language, but a problem of the domain.

The reason for this becomes clearer when you try to make two different implementations of that interface, lets say an AutocadPoint3D (representing a point in an autocad CAD model, with lots of additional data like tags, color, layer etc.) and a GoogleEarthPoint3D (representing a coordinate in an KML model). Now try to add points of those two classes by a method like

   IPoint3D Add(IPoint3D point1, IPoint3D point2)

So what should be the underlying type of the result be? A new AutocadPoint3D, a GoogleEarthPoint3D, or something different (like your SimplePoint)? The only thing which probably makes sense would probably be the SimplePoint, because it is something like the "smallest common denominator" of all 3D points. Moreover, IPoint3D cannot be used to force sealed implementations, so code which relies on IPoint3D cannot be sure the underlying type is always immutable. This might suffer from unexpected side effects when the implementer of the interface is not very careful.

Think about the reason for what purpose you typically use interfaces. The most frequent purpose is probably dependency injection, especially for unit testing. But it seldom makes sense to mock out a value object like Point3D. Imagine you need to test a class which needs an IPoint3D, you would probably inject a SimplePoint object with some predefined values as test data - but then you could also use a SimplePoint directly and save the interface. So the interface only adds "noise" to your code, with no real benefit.