I have been reading about inheritance vs composition. I know there is already allot about this topic on this site, but i have a question about this specific example I hope will not be seen as duplicate.
Some guidelines I have gathered so far:
Prefer composition over inheritance.
Has-a relationship will therefore almost always mean composition.
Is-a relationship CAN mean inheritance is best, but not always.
So now for the example
I have been working on a simple game engine to practice C++. For this I have made some classes:
The Image class that contains an image that can be rendered.
The Transform class is all about positioning.
The Sprite class contains an image that can be rendered, in a specific position.
There is more of course, but let’s keep it simple for the example.
So - Sprite HAS an image and HAS a position (transform). Following the guideline that would mean composition for both. BUT I think it is just so much easier to have Sprite inherit from Transform.
Because I what to do things sprite->setPosition() and sprite ->setScale().
If a Sprite inherits from Transform, I don’t have to do anything, sprite->setPosition() automatically calls Transform::setPosition() for the sprite object.
If Sprite HAS a Transform, I would have to redirect ALL of these kind of methods to the Transform! (It's how I have been doing it so far and it seems to work fine)
I don’t want to write things like this for every positioning method: (there are quite a few already)
Sprite::setPosition(Vector2 position) {
mTransform.setPosition(Vector2 position);
}
But It seems to go against convention.
What do you all think?
When you say "easier" I think you mean "faster", because let's face it, forwarding the calls from the Sprite to the Transform component it's not difficult at all, it just takes more typing (and "less typing" is good, but I would weigh other things first). The problems of choosing inheritance over composition could not be there now, but could arise later.
With public inheritance you just have to declare the inheritance, and all the public interface from Transform is available in Sprite. All. If one day you add a "Rotate" method to the Transform, but don't want Sprites to be shown upside down, then you have to hide the base class method somehow. There are good answers here from Matthieu and CodeFirst about how to do that hiding in C++. But as Matthieu points there, by hiding the method you violate the Liskov Substitution Principle. If you had used composition, you could have just ignored that "Rotate" method in the public interface for Sprite.
With private inheritance you would be a little bit better, because it represents a "is implemented in terms of" relationship between Sprite and Transform, closer to reality than the "is a" relationship represented by public inheritance. But then you would need to put "using" statements to make available the methods from Transform in Sprite (see Eugen answer also in the previous link). So you end up still having to write extra code to achieve your purpose (although less than with composition).
With composition I feel that you have easier options to deal with design problems. Do you want to simply call the component method? You forward the call. Do you want to ban the component method? You don't add it to the Sprite interface. Do you want to add functionality to one method (e.g. keeping the Transform scale from being set to such value that the size of the Sprite Image is too small)? You add the method to the interface but do some extra processing/checkings before/after calling the Transform component...
If you can get your hands on Scott Meyers' Effective C++ book, you have two items that are worth reading for this discussion: "Use private inheritance judiciously" and "Model 'has-a' or 'is-implemented-in-terms-of' through composition". A final point extracted from there in favor of composition: "Both composition and private inheritance mean is-implemented-in-terms-of, but composition is easier to understand, so you should use it whenever you can"
Related
Currently I am trying my best programming a little video game in the style of the old Zelda games. However, I am having some trouble with the whole OOP style of thinking. To be more specific, I don't really know how to "design" the screens.
Let's say I have a class for my sprites and loaded a Wall-sprite to have a border for a certain area, should I make an extra "wall"-class, or is the wall being a "sprite" already enough? I thought it might be senseless to define an extra class since it would not have any different variables than the actual sprite class (as my wall IS only a sprite) so I didn't consider it to be a useful idea.
I am asking this because I have a little problem with the collision detection as well: What I currently do is loading a sprite for an object only once and rendering it multiple times at several locations. But the problem is that this causes the collision only to be detected at the last position the sprite was rendered at.
It gives me more problems when I render 2 cave-entrances somewhere but my game only checks for the 2nd entrance if I "entered" it.
So I thought making an extra "entrance"-class and creating 2 completely different objects of it that are treated separately might help, but should I then also create 30 objects for my wall-sprites?
Hmmm, there is really two questions, well three, but the OOP-thinking is too non-specific for a good question. So let's see if we can answer it by answering your valid ones.
Good OO Design is centered around "Patterns" (Common solutions to a variety of Problems) in the case of your sprite re-use in OO this would be known as a "Fly-weight" Pattern. Three important structural elements in good OO and understanding them is key to "getting it". They are:
Interfaces - They are free (relatively) of operational code, and provide only method and constructor signatures(generally) to allow for clean separation of coding concerns.
Classes - Only the reusable parts(ideally) of an object they are "the Mold or Pattern" that objects are instantiated (or patterned) from.
Objects - Instances (this chair or that chair as opposed, to Chair as an ideal) of the same form of Class (the ideal Chair). Objects (ideally) should keep as instance values only that which differentiates it from other instances of the same ideal.
However, because your original sprite is not an object you are having this collision problem, because it actually is the same instance rendered again and again, the graphics pipeline does not keep all of its previous locations as separate things it actual just stores pixels(usually), once they've been translated.
In this case if each instance is an object, each instance would have its location as a local instance variable(s), while its graphical representation and collision detection method would be common to all instances of the class.
Don't think of it as having 30 whole copies in memory at once, you only have thirty copies of the instance variables. This is true if you use OO or not; in a procedural solution to get proper collision detection you would have to maintain an array of all of the places you rendered that sprite and iterate through each time, further your code would be less cleanly separated and you would have to iterate through the array for every sprite interaction as well as for updating moving sprites. With OO you could handle this with one class method call that recurses it children.
A good class structure for this simple example might be:
An Abstract Sprite Class (abstract because you will never use a non-specific Sprite) containing only code common to all sprites
A Concrete Wall Sprite Class that extends Sprite, only the code for non-moving wall sprites.
A Concrete Trigger Sprite Class (whose graphic might be clear or null) for behaviors that need to be triggered in "open spaces"
A Concrete Agent Sprite Class for moving sprites (might implement a movable interface meaning all derivatives of the class have a move() method.
A Concrete Character class that extends agent for a movable sprite that is driven by user commands.
It may seem confusing at first, but it's actually cleaner, simpler, and more maintainable doing it the OO way.
:)
For some homework, we have to devise an example (with classes) where both the Strategy and Template Method design patterns come together to complement each other and make them more customizable as a result. Or "use template method to provide more customizability to handle a variety of strategies" as it says.
After much reading and initial confusion, I came up with the idea of having two animals as classes, Dog and Snake and have them both use interfaces to implement a specific function, moving (so a dog might walk and a snake would slither). I thought this to be the Strategy pattern portion, as they're each separately implementing their own move functionality.
In order to incorporate the Template Method pattern into this, I thought I'd make it so the class it's implementing is then subclassed further for customizability, which seems to go with the question. So I thought I'd have Mover as the class and have it subclassed down into Walk and Slither. But this confused me as would each animal implement the superclass Mover, or one of the subclasses? And is the superclass Abstract, while the subclasses are Interfaces? Or are they all interfaces?
Does my example make sense?
As Per my Understanding your example does't fit into the Strategy and Template, the Scenario best fits into Abstract Factory and May be Prototype (Depends upon full requirement).
The basic difference between strategy and Template is Inheritance v/s Delegation.
If you are Searching for Strategy and template Example i would suggest you to go with some game application where the Full game can fit into template function like end of game, start the game,Winner of the game looser of the game and the Rules to play the can be fitted into Strategy like when to move, what to do with some moves.
No. The main reason is because Strategy applies when you need to have different ways to do the same thing, e.g. a Layout Manager. In your example, Snakes have one way of moving, likewise Dog.
Frankly, I don't see those patterns as going together so well, not sure what the assignment is after. Template Method is great when things are done in a particular way, and variants merely implement steps of the process differently.
Probably you should think of a process where one of the steps could have a Strategy plugged in.
Your example is OK if you would somehow manage to get appropriate names to BeginMove and EndMove methods in MoverStrategy.
Here:
GetMoveStrategy - FactoryMethod responsible for declaring interface for creation appropriate strategy
MoverStrategy - Strategy
Move - Template method with one placeholder DoMove which Concrete Strategy must define
C++ Should I make one abstract class with many derived classes or just one general class?
Classic example is the abstract Shape object with derived classes Square and Triangle that hold specific geometry and functions.
Why don't I just make one general class called Shape that includes a more general geometry data member to hold a dynamic amount of points that could either be a square or a triangle?
Functions could take some parameter indicating what type of shape it was e.g. Shape.process("square"); instead of something like Square.process();
Is my question clear? Is this purely a stylistic choice?
You should avoid creating "god" classes that do a bunch of stuff. What if you will have to implement a lot of shapes? A class should have only one responsibility, should be open for extension and closed for modifications. Check the class design principles or the SOLID principles of design. You should avoid complicated design and big classes that have multiple responsibilities just because at a moment it will become a pain to maintain them or add extra functionality. Unit testing will also be something more easy to do with a good design.
You cannot get an answer to this type of question in general. It is going to depend on the situation and requirements for whatever problem you are attempting to solve. In some cases, it will make sense to have an interface with derived classes. In others, it will make sense to have a generalized class. Without knowing the requirements for the problem, you will get no real answer.
It really depends on what you need the Shape for. For example if you are just drawing it, then yeah a general Shape class that just draws line from point to point would be perfect (for polygons anyway). But what if you wanted to calculate the area. It would probably be easier to have a Square and Triangle class where the getArea() function uses the appropriate area formula. There is no hard and fast rule it simply depends on what you need them for
My goal is to implement a (very simple) strategy game.
For the moment, I'll start with the map and two characters (I want the terrain to affect them differently) to experiment with pathfinding
The problem is that I have very little or no experience in object oriented design. I've used C++ classes before, but it was pretty straightforward: for instance, a class Graph implemented using an array of sets, with a method AStar. I didn't have in mind the concept of "several players".
I've thought of the following elements/classes: Game, Map and Character. Eventually a Pathfinder class.
First question: the position of a character is something the game should know? The map? or each character?
( I think the game should )
Second question: where would it be a good choice for a "findPath" method?
The Game?
Should a pathfinding algorithm be a method of Map? Something like map.findPath(character, srcpos, dstpos)
In the Character class? It makes more sense to do character1.findPath(map, srcpos, dstpos)
If I added a Pathfinder class, it would have to build its own representation of the map in order to determine the shortest path. And before doing that, it would have "to ask" the map how the terrain affects each player.
( I prefer the latter )
It seems the construction of an auxiliary structure (and asking the map) to apply, let's say, A* is something that I can't avoid.
Making things object-oriented is not a goal, it's a tool to be used when it makes sense. C++ is a language with lots of functionality that you can easily drown yourself with, so my advice is to keep things simple and easy.
This can mean keeping data and logic tightly together sometimes, or separating it completely other times.
First question: My initial reaction is that the character should know its position. But how you represent it with data depends on how you intend to use it, so both the game, the character and potentially also the map needs to know where the character is.
Second question: It depends on what the Map class is. Is it an object representing the map itself with necessary functionality exposed to the rest of your program, or is it a toolbox of functions that works on a simple data representation of the map?
If the Map class represents the map, it should have the necessary functionality exposed for a Pathfinder class to work on it (the pathfinding algorithm will need to have some additional data derived from the map, maybe temporary, maybe persistent).
If the Map class does not represent the map, you can put the pathfinding functionality in it. I think it would belong there in that case. If the pathfinding code causes the Map class to get too big, you should separate it into its own class anyway.
First Question: The position of the character should be a part of character itself (makes sense this way) for me.
Second Question: Finding a path logically cannot be a part of Map. Then you would be violating one of OOP principles i.e. Single Responsibility.
According to me you should create the PathFinder class. You can design it in this way
class PathFinder{
PathFinderAlgorithm algorithm;
//other required values according to your design
Path findPath(){
algorithm.apply();
}
//other required methods according to your design
}
PathFinderAlgorithm is an interface.
Using this you can also change the algorithm that you are using to find the path. Like if you in future need to find the longest path, all you have to do is create another class which will find the longest path and replace it in the PathFinder class.
This is sort of a methodology question.
When writing software that makes use of object-oriented libraries to abstract OpenGL and the like, should you (or would you) choose to extend the OpenGL helper objects and add your own business logic onto them, or create your basic business objects and then have the OpenGL helpers as a property of them.
For example
Let's say I have an OpenGL library that provides a class
OpenGLBillboard
which draws a 2D sprite that faces the camera
if I have some sort of business object that is going to be rendered using that class, is it wise to simply extend OpenGLBillboard and build on top of it, or should I just have an OpenGLBillboard object that is a property on what is essentially a base class in my software?
It seems like inheritance in this case could be dangerous because if the base class ever has to change due to requirements, the refactoring could be painful ... whereas if I just go the property route, I have a little more upfront boilerplate to write.
Your thoughts?
Thanks
P.S. forgive me for saying "business object". I just didn't want to say "model" a whole lot in a topic about 3D and have people be confused as to my meaning.
Personally, I would probably have my business object contain (privately) a "Billboard" instance, and not tie it directly to OpenGL at all.
The business object would just be asked to render, and redirect it's methods through the Billboard instance. This would allow you to swap out a different implementation (if you decide to go with something other than a Billboard) or a different backend (ie: a Direct3D rendering pipeline) without changing the business object at all.