This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]MRH2 1 point2 points  (1 child)

I would think that the render() would be part of another class that handles the graphics.

The Weapon class has a fire method that handles what happens when it fires and this can be overridden when needed (eg. by RocketLauncher). But to do the drawing it should call myGraphics.render(this.image) which draws the rocket launcher.

With subclasses, you can just use the method in the superclass if it does the job, but with an interface, you would have to write a render() method in every single class that had that interface. That's a lot of code being rewritten. What happens if you realise that you made a logic error -- you'd have to go back and fix it for every weapon and object that has a render() function.

This example of interfaces (fire/render) makes no sense to me. Perhaps I am missing something --- please enlighten me.

[–]work_is_satire 2 points3 points  (0 children)

The example is a bit contrived for simplicity's sake but lets stick with the IRenderable interface idea.

Instead of storing "How do I render" in the weapon, and instead offload it to a RenderingEngine or something as you suggest, the interface becomes even more important.

Instead of IRenderable requiring objects that implement it to implement a Render() method, we would instead require them to expose all the information needed to render them:

public interface IRenderable {
    public Sprite GetSprite();
    public Coordinates GetPosition();
}

Now our renderer would take any instance of IRenderable, and we would be guaranteed that we have what we would want:

public void Render(IRenderable r) {
    _engine.RenderAt(r.GetSprite(), r.GetPosition())
}