Re: Question about large objects
On Apr 24, 11:16 pm, JoeC <enki...@yahoo.com> wrote:
On Apr 23, 10:48 pm, Kirit S=E6lensminde <kirit.saelensmi...@gmail.com>
wrote:
On Apr 24, 9:10 am, JoeC <enki...@yahoo.com> wrote:
On Apr 20, 11:40 pm, Kirit S=E6lensminde <kirit.saelensmi...@gmail.co=
m>
wrote:
On Apr 20, 10:53 pm, JoeC <enki...@yahoo.com> wrote:> I have been w=
riting games and I also read about good programming
techniques. I tend to create large objects that do lots of thing=
s. A
good example I have is a unit object. The object controls and ho=
lds
everything a unit in my game is supposed to do. What are some so=
me
cures for this kind of large object or are they OK because they
represent one thing. If not what are better ways to design objec=
ts
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?ClassicOoAntiPatternsandespeciallyhtt=
p://c2.co...
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
I have looked into java a bit and everything is an object there.
For this object the best I can do is seperate out the movment into a
movable class. It seems like every variable should be an object.
Object, set and get. It just seems like a great deal of unnecessary
overhead. I know it is a simple question but what is the rational for
such small classes? Most of the class are these facors:
I know what you mean about it seeming to be a lot of work. The flip
side is that collapsing the small classes into the larger class is in
effect an optimisation and we all know that premature optimisation is
evil :-) This is why you get away with it on small projects, but on
larger projects it will start to cause problems. Eventually it can get
so bad that it is effectively impossible to continue to maintain the
software.
Take a read of a couple of my papers on encapsulation and accessors.
http://www.kirit.com/On%20following%20rules/Encapsulation%20is%20a%20Good%2=
0Thing%E2%84%A2
This first one describes why encapsulation came about and then
describes what sorts of attributes should get read and write
accessors.
http://www.kirit.com/C%2B%2B%20killed%20the%20get%20%26%20set%20accessors
The second shows a simple template technique that can be used to write
accessors with virtually no typing overhead. By keeping the syntax in
a certain form they can be replaced with more complex accessors later
on without having to edit all the code that uses the class.
For the attributes that you listed I'm not really sure what they're
meant to do as the names aren't always that illuminating (for example
"move", "moved", "dmove"), so I'll give another example that may be
relevant.
Let's assume we split off a small class for storing the location of
the unit which has x() and y() members. So if we have an instance
"unit" we can do this:
unit.position().x();
unit.position().y();
Let's then assume that you write some A* path finding so that the unit
can come up with a plan for how it will move over the next few
minutes. It can store this in a list now:
Attribute< std::list< Location > > plan;
*unit.plan().begin(); // The next waypoint the unit is moving towards.
By simply splitting this little class out you've gained the ability to
handle a bit of forward planning for your units. If you'd kept the x/y
co-ordinates within the unit directly then this extra bit would never
have occurred to you. You could still manage the same thing, but it
would have been much more messy.
To update the location you could have this:
unit.position().x( unit.position().x() + 1 );
unit.position().y( unit.position().y() + 1 );
This is what you'd do if you didn't have the Location class, but with
it you can do something a bit neater. What if Location contained a
moveTowards() member?
unit.position().moveTowards( *unit.plan().begin(), unit.speed() );
Now you've tied together the position, the speed and the plan in a
fairly neat way. You also get the benefit that the movement
calculations are in one place (moveTowards).
These benefits may not be obvious to start with, but if you try
working in this way you'll see that what you're doing is keeping a lid
on the complexity. It means that you can tackle something much larger
and much more complex because everything is managed into smaller
chunks.
K