Understanding Classes

[brian void]

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

 

[Tomas Mikula]

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

 

[Tomas Mikula]

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

 

[markspace]

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.

 

[Roedy Green]

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

 

[Andreas Leitgeb]

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: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 { ... }

 

[Donkey Hottie]

Another misnomer of the OP:
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.

 

[Andreas Leitgeb]

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

 

[Lew]

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.

 

[alexandre_paterson]

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).

 

[alexandre_paterson]

class Robot {
... has some methods

}

interface Jumping {
... more methods

}

interface Colors {
... more methods

}

class RobotJumping implements Jumping {
... implementation

}
class RobotColors implements Colors {
... implementation

}

That's one way to do it.

Here's how the OP could do it using only interfaces
(re-using the OP's names):

interface Robot {
...
}

interface Jumping {
void jump();
}

interface Colors {
void color();
}

final class Karel implements Robot, Jumping, Colors {
...
}

Or:

interface RobotJumping extends Robot {
...
}

interface RobotColors extends Robot {
...
}

final class Karel implements RobotJumping, RobotColors {
...
}

(hoora, screw the diamond problem here, this is Java MI

And why not:

interface Transformer extends Robot, Jumping, Colors {
...
}

final class SuperKarel implements Transformer {
...
}

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.

But "code reuse" (which really is what implementation inheritance is)
can also be a PITA because it ties the "OO" part of the application to
concrete implementation and it makes later changes much harder to
translates/implement/fix.

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

IDEA doesn't just write the methods skeletons, it also generates
all the delegated method calls to the wrapped subject.

 

[alexandre_paterson]

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

 

[Lew]

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).

I don't know that that makes life harder for beginners than anything else.
It's not a very complicated concept in Java.

Still, it's best for beginners to think of object-oriented structures as based
on "types", then follow Joshua Bloch's advice and use interfaces to represent
types. Put off thinking about classes for a while, when you are focused on
object-oriented concepts more intellectually. However, Java is also a highly
pragmatic language, and sooner or later one's code has to do something actual.
So when thinking pragmatics one can comprehend classes as reification for types.

Really, even for beginners this should be only a few minutes' thinking.

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.

Inheritance of classes is easy to overuse. You can mix in any number of
interfaces to a concrete class and generally that will suffice.

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

And OO is god.

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

Well, you have my sympathy on the database and kudos for your class
implementation.

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...

If by "good" you mean "useful" or "often saves labor" or "quite handy if used
correctly", then yes, it is good to have implementation inheritance available.

As with nearly all techniques, you don't have to use it just because you can.

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

I lost your antecedent there. Are you saying that concrete inheritance is
misleading for OO beginners?

Of course, it's only "misleading" in that it leads people to think about
things differently from how you personally feel they ought to think, given
that OO is god. If it even does that. I feel certain that anyone reading any
responsible literature on object-oriented programming will be able to spot
areas where Java differs from at least some of those theoretical models.
There's nothing about Java as a language that promises to be "pure" in some
purist's sense of the word, and if it isn't promising to be something that it
isn't then it isn't misleading anyone.

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'.

Programs that use concrete inheritance can be simpler to maintain than with
other approaches. It's a useful technique.

At times.

 

[markspace]

IDEA doesn't just write the methods skeletons, it also generates
all the delegated method calls to the wrapped subject.

That's nice. They'll have to get that feature into NetBeans soon.

Actually if I'd known about Project Coin, I might have suggested
something for the Java compiler like that. For example:

Mix-ins for Java

Allow the interface of a class to specify an instance variable which
implements that interface:

class Karel extends Robot implements Jumping(jump), Colors(color)
{

Jumping jump;
Colors color;

... etc. rest of class ...
}

Here, the Jump interface would be implemented by the jump instance
variable. All methods in the Karel class would be implemented by the
compiler to just call the same method on the variable jump. And the
same for the Colors interface and the color variable.

I'm undecided whether the instance variables which implement an
interface should be required to be final (my preference is not) or
should be allowed to be an interface type or an abstract type, instead
of required to be a concrete type (my feeling is that abstract or
interface types are ok).

My 2 nickels.

 

[Donkey Hottie]

Mix-ins for Java

Allow the interface of a class to specify an instance
variable which implements that interface:

class Karel extends Robot implements Jumping(jump),
Colors(color) {

Jumping jump;
Colors color;

... etc. rest of class ...
}

Here, the Jump interface would be implemented by the jump
instance variable. All methods in the Karel class would
be implemented by the compiler to just call the same
method on the variable jump. And the same for the Colors
interface and the color variable.
I'm undecided whether the instance variables which
implement an interface should be required to be final (my
preference is not) or should be allowed to be an
interface type or an abstract type, instead of required
to be a concrete type (my feeling is that abstract or
interface types are ok).
My 2 nickels.

That's sorter in C++

class Karel : Robot, Jumping, Colors
{

} ;

What we need in Java is (obviously) multiple inheritance, WITH the
interfaces (pure abstract class in c++).

(But more that that, we need unsigned keyword).

My 2 nickels.

 

[markspace]

That's sorter in C++

Sorter? Shorter?

What we need in Java is (obviously) multiple inheritance, WITH the
interfaces (pure abstract class in c++).

I know what multiple inheritance is and how it works in C++ (at least in
general, I'm no expert on it). Multiple inheritance was left out of
Java on purpose. I'm fine with that. My mix-ins was an attempt to
bridge the gap without having to bring true multiple inheritance into Java.

(But more that that, we need unsigned keyword).

I'm actually ok with the lack of an unsigned keyword too. There's just
a few niggles in Java, such as the choice of a signed byte. We might be
getting some syntactic sugar to paper over this in Java 7.

 

[Donkey Hottie]

My mix-ins was an
attempt to
bridge the gap without having to bring true multiple
inheritance into Java.

And I say better without any attempts. Bring it to the language.

Let the programmer decide when it is needed.

class Sub
extends Sup1, Sup2, Sup3
implements Comparable<Super>, Serializable
{
}

I'm actually ok with the lack of an unsigned keyword too.
There's just
a few niggles in Java, such as the choice of a signed
byte. We might be getting some syntactic sugar to paper
over this in Java 7.

cool