Re: Understanding Classes
On Jul 21, 1:37 pm, brian void <brian.voi...@gmail.com> wrote:
....
But then if I want to make Karel jump I have to create and instance of
KarelJumps rather the SuperKarel. But because KarelJumps is a
different object then KarelColor I couldn't use any of its methods.
So would I just put all of the KarelJumps and KarelColor methods
inside SuperKarel? Do I just make one large object?
If your SuperKarel can actually jump and color (is it colorizing stuff
, does he have a color, is it colorizable?) then, yup, it's going to
be
"one object" responding to such messages (jump / color / etc.) (not
with
the way you modelled it that said, see what markspace suggested to
you).
But from your code you won't necessarily always refer to your
SuperKarel
as a SuperKarel.
If you have, amongst other, those interfaces:
interface Jumping {
... more methods
}
interface Colors {
... more methods
}
Then in your code you may have lines like this:
Jumping j = findClosestJumpableRobot();
j.jump();
(you re referring to your SuperKarel simply as a Jumping object,
because that's all your care about here)
Colors c = findFirstColorizableRobotAtSprayDistance();
c.colorize();
The cool thing is that you may have the following:
Kangaroo implements Animal, Jumping {
...
}
and then:
Jumping j = findClosestJumpableThing();
and that line may return you either a Kangaroo or
a SuperKarel or something that can respond to the
"jump()" message but that hasn't been identified
yet in your customer's problem space.
That's the beauty of OO :)