«

Hi I'm new to programming and have some questions about classes.

I'll use Karel as an example:

public class Karel extends robot{
....
}

then I extend Karel:

public class SuperKarel extends Karel{
....
}

but then I want to organize some groups of methods(?)

public class KarelJumps extends SuperKarel {
....
}

public class KarelColor extends SuperKarel {
....
}


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?

Thanks in advance,

Brian

On Jul 21, 2:37*pm, brian void <brian.voi...@gmail.com> wrote:
> Hi I'm new to programming and have some questions about classes.
>
> I'll use Karel as an example:
>
> public class Karel extends robot{
> * *....
>
> }
>
> then I extend Karel:
>
> public class SuperKarel extends Karel{
> * *....
>
> }
>
> but then I want to organize some groups of methods(?)
>
> public class KarelJumps extends SuperKarel {
> * * ....
>
> }
>
> public class KarelColor extends SuperKarel {
> * * ....
>
> }
>
> 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?
>
> Thanks in advance,
>
> Brian

Karel and SuperKarel are classes, KarelJumps and KarelColor are
methods. Methods are not classes. A class encapsulates related data
(members) and actions (methods). So jump and color would be methods of
class SuperKarel.

public class SuperKarel extends Karel {
public void jump(){
// your jumping code
}
public void color(){
// your coloring code
}
}

Tomas

On Jul 21, 3:50*pm, Tomas Mikula <tomas.mik...@gmail.com> wrote:
> On Jul 21, 2:37*pm, brian void <brian.voi...@gmail.com> wrote:
>
>
>
> > Hi I'm new to programming and have some questions about classes.
>
> > I'll use Karel as an example:
>
> > public class Karel extends robot{
> > * *....
>
> > }
>
> > then I extend Karel:
>
> > public class SuperKarel extends Karel{
> > * *....
>
> > }
>
> > but then I want to organize some groups of methods(?)
>
> > public class KarelJumps extends SuperKarel {
> > * * ....
>
> > }
>
> > public class KarelColor extends SuperKarel {
> > * * ....
>
> > }
>
> > 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?
>
> > Thanks in advance,
>
> > Brian
>
> Karel and SuperKarel are classes, KarelJumps and KarelColor are
> methods. Methods are not classes. A class encapsulates related data
> (members) and actions (methods). So jump and color would be methods of
> class SuperKarel.
>
> public class SuperKarel extends Karel {
> * *public void jump(){
> * * * // your jumping code
> * *}
> * *public void color(){
> * * * // your coloring code
> * *}
>
> }
>
> Tomas

And then if you want to make Karel jump, you make an instance of
SuperKarel and call its jump() method. You will use the same instance
of SuperKarel to make him color:

SuperKarel karel = new SuperKarel();
karel.jump();
karel.color();

Tomas

brian void wrote:

> So would I just put all of the KarelJumps and KarelColor methods
> inside SuperKarel? Do I just make one large object?


To answer literally, yes, your only recourse here is to make one big class.

However...

Tomas Mikula had a good point, what you are doing seems to be just
adding methods to classes. Your classes for jumping and colors seem
over-kill. So there's one idea, if you are totally stuck on how to do
what you asked.

This doesn't seem like a "new" question, but if you're asking about
decomposing classes, Java does not have multiple inheritance. You
simulate multiple inheritance with composition and interfaces.


class Robot {
... has some methods
}

interface Jumping {
... more methods
}

interface Colors {
... more methods
}

class RobotJumping implements Jumping {
... implementation
}

class RobotColors implements Colors {
... implementation
}


class Karel extends Robot implements Jumping, Colors {

private Jumping jump = new RobotJumping();
private Colors colors = new RobotColors();

... implement Jumping and Colors in terms of the
classes above, by hand.

}

Unfortunately you have to now type all methods exposed by the interfaces
Jumping and Colors and implement them. It's better than just one huge
class, because the Karel class is "thin" and just delegates to other
classes. It can be a PITA because it's still lines of code you have to
type, test and maintain.

Many IDEs will write the methods for you for Jumping and Colors. You'll
still have to implement the method bodies yourself though.

On Tue, 21 Jul 2009 05:37:22 -0700 (PDT), brian void
<> wrote, quoted or indirectly quoted someone
who said :

>public class Karel extends robot{

You are confusing yourself by ignoring conventions.
Classes must start with a capital letter, methods with lower case.

Methods are not classes. They belong to a class.
--
Roedy Green Canadian Mind Products
http://mindprod.com

"The industrial civilisation is based on the consumption of energy resources that are inherently limited in quantity, and that are about to become scarce. When they do, competition for what remains will trigger dramatic economic and geopolitical events; in the end, it may be impossible for even a single nation to sustain industrialism as we have know it in the twentieth century."
~ Richard Heinberg, The Party’s Over: Oil, War, and the Fate of Industrial Societies

Roedy Green <> wrote:
> On Tue, 21 Jul 2009 05:37:22 -0700 (PDT), brian void said :
>> public class Karel extends robot{
> You are confusing yourself by ignoring conventions.
> Classes must start with a capital letter, methods with lower case.

I do agree to the use of "must" here. It's not really a compiler
requirement, but one of those conventions, that one is so strongly
advised to follow, that one should *think* of it as a "must".

Another misnomer of the OP:
>> class SuperKarel extends Karel { ...
Here, "SuperKarel" is a *Sub* (not Super) class of Karel.
Instead, "Karel" is "SuperKarel"s Super class.

Java inheritence tree must be imagined with "Object" at the top,
and all other classes hanging directly or indirectly down from it.
This orientation of the tree was (probably) a random choice by the
Java inventors, but it's important that everyone talking of Java
class hierarchies thinks of the same relation when calling one
class "above"(Super) or "below"(Sub) some other class.

class SuperKarel { ... } // directly "below" Object
class Karel extends SuperKarel { ... }
class SubKarel extends Karel { ... }

"Andreas Leitgeb" <> wrote in
message news:
>
> Another misnomer of the OP:
>>> class SuperKarel extends Karel { ...
> Here, "SuperKarel" is a *Sub* (not Super) class of Karel.
> Instead, "Karel" is "SuperKarel"s Super class.
>
> Java inheritence tree must be imagined with "Object" at
> the top, and all other classes hanging directly or
> indirectly down from it. This orientation of the tree was
> (probably) a random choice by the Java inventors, but
> it's important that everyone talking of Java class
> hierarchies thinks of the same relation when calling one
> class "above"(Super) or "below"(Sub) some other class.
>
> class SuperKarel { ... } // directly "below" Object
> class Karel extends SuperKarel { ... }
> class SubKarel extends Karel { ... }

It is possible that OP ment SuperKarel as a "better Karel", thus Super. He
propably was not thinking super or sub classes of OOD.

Just like the subclass of Hornet is SuperHornet in US Navy.

Dunno.

Donkey Hottie <> wrote:
> "Andreas Leitgeb" <> wrote:
>> Another misnomer of the OP:
>>>> class SuperKarel extends Karel { ...
> It is possible that OP ment SuperKarel as a "better Karel", thus Super. He
> propably was not thinking super or sub classes of OOD.
> Just like the subclass of Hornet is SuperHornet in US Navy.

Even if I were familiar with aircrafts, I'd feel uneasy to write:
class SuperHornet extends Hornet ...

I doubt, that any real-world "super-" relation would translate
well into either a sub- or super- class relation in a class design.

A "Super-" in real world usually isn't bound by any "Normalo-"
contracts

--
PS: I just returned from a one week visit to Helsinki

Tomas Mikula wrote:
> And then if you want to make Karel jump, you make an instance of
> SuperKarel and call its jump() method. You will use the same instance
> of SuperKarel to make him color:
>
> SuperKarel karel = new SuperKarel();
> karel.jump();
> karel.color();

I'm going to assume a parent class for 'Karel' called 'ParentKarel' to clarify
a point.

ParentKarel karel = new Karel();
karel.jump();
karel.color();

As long as jump() and color() are overridable methods of 'ParentKarel', this
will invoke the implementations of those methods according 'Karel', the
subtype. This is polymorphism.

--
Lew

On Jul 21, 1:37 pm, brian void <brian.voi...@gmail.com> wrote:
> Hi I'm new to programming and have some questions about classes.

You can learn OO concept using Java, but it may not be the
best option.

The problem is that Java makes it very hard on OO beginners by
providing two keywords to define an OO class: 'class' and
'interface' (similar -but not identical- to a C++ pure abstract
class).

With Java 'class', you only have single inheritance. With Java
'interface', you have multiple inheritance.

You can decide to live with it and model your OO hierarchy by
both extending concrete classes (and abstract classes) and
interfaces in your codebase.

But to me (and quite some others) this is a huge mistake: you'd
really be mixing two different things and mix up implementation
details with your OO model. Implementation details do not exist
at the OO-Analysis/OO-Design level.

First, I like to have a pure mapping from my OOD to my
Java interfaces. Then the translation OOD -> OOP is often
not possible using single inheritance.

Most people don't realize this, but it's because they hardly
do OO at all.

On the small codebase I'm working on at the moment
(6 digits LOC) every single class is 'final' and there
is not a single instance of the 'abstract' keyword. And
multiple inheritance is used everywhere. And we're doing
persistence using an OO DB

Anyway, you'll have people arguing that having the ability
to extend a concrete class is a good thing (even tough
James Gosling himself said he regretted "not having gone
pure interface") but...

You'll have way less people arguing that this is not
completely and utterly misleading for OO beginners.

So IMHO Java could have been both simpler and cleaner
by removing the 'abstract' keyword and by preventing
to 'extend' (Java) classes but I'm one of those few
that like the mathematical definition of the word
'elegant'.



(see my respond to markspace for yet another way to
do it, without ever extending any concrete class).