Re: Question about large objects
On Apr 24, 9:10 am, JoeC <enki...@yahoo.com> wrote:
On Apr 20, 11:40 pm, Kirit S=E6lensminde <kirit.saelensmi...@gmail.com>
wrote:
On Apr 20, 10:53 pm, JoeC <enki...@yahoo.com> wrote:> I have been writi=
ng games and I also read about good programming
techniques. I tend to create large objects that do lots of things. A
good example I have is a unit object. The object controls and holds
everything a unit in my game is supposed to do. What are some some
cures for this kind of large object or are they OK because they
represent one thing. If not what are better ways to design objects
that behave the same way. Would it be better to use inheritance or
friends and where can I look to be able to do the same thing in a
better way?
Here is a unit from a completed game I created. The header file at
least to give an idea of one of my larger objects.
[snip huge class]
You're using the class more like a namespace here. Objects should be
cohesive, which is a word that takes a look of thinking about to
really understand. A simple definition is that they should do only one
thing and do that one thing well. The smaller the scope of the one
thing they do the better.
Look athttp://c2.com/cgi/wiki?ClassicOoAntiPatternsandespeciallyhttp://=
c2.com/cgi/wiki?ClassesWithoutOo
K
This is what I am asking. I use namespace std other than that I have
little experience or information on creating or using one. Most of
the stuff in my unit objects affect other thing in that object. I can
understand the graphics part and it has graphics and it would be good
to create a movable object and derive that into my class. I came up
with this after the game was done when I went back and tried to learn
lessons from my project.
As an exercise see how small you can make your class by putting things
into helper classes. Look for things that are logically grouped. It'll
take you a while to work through the dependencies to get them right,
but your aim is to try to reduce your main class into the absolute
minimum that you can.
When you do it you should try to arrange the classes such that the
members of the unit class don't need to know that unit exists. I.e.
that every class you use as an attribute doesn't know anything about
the class that uses it. This is an ideal and isn't always possible,
but think very carefully before breaking it -- never do it until
you've exhausted every other possibility.
K