Java and OOP

[soup_or_power]

I was asked by a colleague Java is not a true OOP, why? My response
was every class added by the user derives methods from Object class.
Is that correct?

Also, can anyone comment on delegation which is an alternative to OOP?
Can multiple inheritance be done with delegation? What if a user
defined class has to inherit from an API?

Thanks for your help

 

[Joshua Cranmer]

I was asked by a colleague Java is not a true OOP, why? My response
was every class added by the user derives methods from Object class.
Is that correct?

Uh... Inheritance is considered to be a core principle of OOP.

The biggest deviation between "true" OOP and Java is that not /all/
types in Java are objects. Most notably, primitive types are not objects
(which, in retrospect, was almost definitely a mistake). Code blocks and
methods are also not objects (although one can obtain a method handle
via reflection), although I can see debate as to whether or not a "true"
OOP needs to have code blocks as objects.

 

[Stefan Ram]

I was asked by a colleague Java is not a true OOP, why?

This is neither correctly formed direct speech nor
correctly formed indirect speech.

Direct speech would required quotations marks, like

I was asked by a colleague: "Java is not a true OOP, why?"

Indirect speech would require another wording, like

I was asked by a colleague whether Java was a true OOP.

My response was every class added by the user derives methods
from Object class.
Is that correct?

I have not witnessed this event, so I can not know, whether
this was really your response.

The to the question answer depends, of course, on the
definition of »true OOP«.

There are several definitions available, so first you and your
colleague need to agree on the definition of »true OOP« to be
used for the discussion following.

Also, can anyone comment on delegation which is an alternative to OOP?

Usually one would not say that it is »an alternative to OOP«.

This suggest that you use non-standard meanings of at least
one of those words (»delegation« and/or »OOP«). So maybe you
need to disclose those meanings here, when you want to discuss
this topic.

Can multiple inheritance be done with delegation?

In Java, there is multiple inheritance of interfaces, not of
implementations. But it is never done using delegation.

What if a user defined class has to inherit from an API?

In Java, classes might »extend« other classes.

 

[Stefan Ram]

Supersedes: <[email protected]>

I was asked by a colleague Java is not a true OOP, why?

This is neither correctly formed direct speech nor
correctly formed indirect speech.

Direct speech would required quotations marks, like

I was asked by a colleague: "Java is not a true OOP, why?"

Indirect speech would require another wording, like

I was asked by a colleague whether Java was a true OOP.

My response was every class added by the user derives methods
from Object class.
Is that correct?

The answer to the question depends, of course, on the
definition of »true OOP«.

There are several definitions available, so, first, you and your
colleague need to agree on the definition of »true OOP« to be
used for the discussion following.

Also, can anyone comment on delegation which is an alternative to OOP?

Usually one would not say that it is »an alternative to OOP«.

This suggest that you use non-standard meanings of at least
one of those words (»delegation« and/or »OOP«). So maybe you
need to disclose those meanings here, when you want to discuss
this topic.

Can multiple inheritance be done with delegation?

In Java, there is multiple inheritance of interfaces, not of
implementations. But it is never done using delegation.

What if a user defined class has to inherit from an API?

In Java, classes might »extend« other classes.

 

[Lew]

Supersedes: <[email protected]>

As our experience some months back with the malicious spoofer indicated, few
news hosts honor the "Supersedes" header.

 

[Arne Vajhøj]

I was asked by a colleague Java is not a true OOP, why?

Java is an object oriented language according to common
definitions.

My response
was every class added by the user derives methods from Object class.
Is that correct?

It is correct, but not important for whether Java is object
oriented.

Also, can anyone comment on delegation which is an alternative to OOP?

Delegation is not an alternative to OOP. It works fine with OOP.

Can multiple inheritance be done with delegation?

No. And Java does not support multiple inheritance.

What if a user
defined class has to inherit from an API?

You can not inherit from an API. You can inherit from a class
in an API. That happens a lot.

Arne

 

[Arved Sandstrom]

I was asked by a colleague Java is not a true OOP, why? My response was
every class added by the user derives methods from Object class. Is that
correct?

Like the other respondents said, what is "true" OOP? Joshua's right,
though - if there is any such definition it's that all values are objects.

Also, can anyone comment on delegation which is an alternative to OOP?
Can multiple inheritance be done with delegation? What if a user
defined class has to inherit from an API?

Thanks for your help

Delegation is not an alternative to OOP, because object-oriented is not
just about inheritance. Delegation in OOP is when one object assigns some
of its responsibilities to another.

As you know Java does not support multiple implementation inheritance
(extending more than one superclass). People would generally use multiple
interfaces and/or delegation to accomplish the same ends. The use of
interfaces is to establish a contract for the implementation class, and
also because you can refer to an instance of such an implementing class
by an interface type that it implements. Note that an _interface_ can
extend multiple interfaces, so if you wanted the effect of multiple
inheritance, you might have interface C that extends interfaces A and B,
an implementation class for the method signatures in A and B (and
potentially also C if it added any), and then refer to an object
elsewhere as being of type interface C.

As far as inheriting from an API, why not just implement it?

AHS

 

[Lew]

As you know Java does not support multiple implementation inheritance
(extending more than one superclass). People would generally use multiple
interfaces and/or delegation to accomplish the same ends. The use of
interfaces is to establish a contract for the implementation class, and
also because you can refer to an instance of such an implementing class
by an interface type that it implements. Note that an _interface_ can
extend multiple interfaces, so if you wanted the effect of multiple
inheritance, you might have interface C that extends interfaces A and B,
an implementation class for the method signatures in A and B (and
potentially also C if it added any), and then refer to an object
elsewhere as being of type interface C.

This is a hint to one of the more powerful ways of developing in Java (or C#
or other OO languages) - type-based analysis and programming. Interfaces can
be used for a few things, but their main purpose is to express type. Multiple
interface inheritance/implementation is thus equivalent (sort of) to type
intersection.

public class Amazing implements Detergent, FloorWax ...

Generics provide another powerful tool for type analysis and programming.
They cement the type averrals even more solidly.

The idea is that you express your design and as much of your program as you
possibly can (and more) as types, i.e., interfaces. Yes, you instantiate
concrete classes at declaration, but the rest of the behaviors are all
according to the interfaces those classes implement.

This is called "Design by Contract", or as I informally label it, "Programming
to Interfaces", or more exactly, "... to Types".

 

[soup_or_power]

Java is an object oriented language according to common
definitions.


It is correct, but not important for whether Java is object
oriented.


Delegation is not an alternative to OOP. It works fine with OOP.


No. And Java does not support multiple inheritance.


You can not inherit from an API. You can inherit from a class
in an API. That happens a lot.

Arne

Thank you all for the clarification. English is not my strong suite,
so please bear with me.

Suppose I have an API with a class called APIClass.

In my app, I define a class

public class MyAppClass extends JFrame {}

Now how do I inherit the APIClass without rewriting the APIClass say
as an interface?

Ideally the MyAppClass has to extend JFrame and implement APIInterface
as:

public class MyAppClass extends JFrame implements APIInterface {}

In other words, without rewriting the API there is no way to inherit
from the APIClass.

Right or wrong?

Thanks

 

[Lew]

Suppose I have an API with a class called APIClass.

You should avoid using 'Class' as part of a class name.

In my app, I define a class

public class MyAppClass extends JFrame {}

Now how do I inherit the APIClass without rewriting the APIClass say
as an interface?

You don't.

You instantiate a member of 'MyApp' (redundant name part 'Class'
removed) or local variable of type 'API'.

If 'API' implements business logic, you don't want to inherit it and
GUI logic together anyway. Keep your business-domain model and GUI
stuff in separate layers.

Ideally the MyAppClass has to extend JFrame and implement APIInterface

That is likely very far from ideal.

as:

public class MyAppClass extends JFrame implements APIInterface {}

In other words, without rewriting the API there is no way to inherit
from the APIClass.

Correct, and be glad it's so.

Prefer composition to inheritance. (See /Effective Java/ by Joshua
Bloch.)

Prefer loose coupling to tight coupling. Keep model and view
separate.

 

[Arved Sandstrom]

[ SNIP ]
Thank you all for the clarification. English is not my strong suite,
so please bear with me.

Suppose I have an API with a class called APIClass.

In my app, I define a class

public class MyAppClass extends JFrame {}

Now how do I inherit the APIClass without rewriting the APIClass say
as an interface?

Ideally the MyAppClass has to extend JFrame and implement APIInterface
as:

public class MyAppClass extends JFrame implements APIInterface {}

In other words, without rewriting the API there is no way to inherit
from the APIClass.

Right or wrong?

Thanks
***************************************************

Apart from agreeing with Lew, it seems to me that you probably have a real
API in mind. If it's not disclosing any secrets, what is it and what are you
trying to do?

Where I specifically agree with Lew is, assuming you didn't pick JFrame as
just a random example, and assuming this API is not related to creating a
GUI, I wouldn't mix things up like this.

AHS

 

[RedGrittyBrick]

Suppose I have an API with a class called APIClass.

In my app, I define a class

public class MyAppClass extends JFrame {}

Now how do I inherit the APIClass without rewriting the APIClass say
as an interface?

Ideally the MyAppClass has to extend JFrame and implement APIInterface
as:

public class MyAppClass extends JFrame implements APIInterface {}

"Favor Composition over inheritance" - Joshua Bloch.


I'm no expert but I'll throw in my ¤0.02 worth anyway

If APIClass *must* be subclassed for some reason, I'd have

public class MyAppClass extends APIClass {
private JFrame frame;
}

I've never encountered a case where JFrame *must* be extended rather
than encapsulated (this doesn't mean that such cases don't exist, just
that I can't think of one).

If MyAppClass subclassing APIClass is undesirable, maybe I'd have
MyAppClass compose a subclass of APIClass, this leaves MyAppClass free
to extend some other class (or not).

As I said, just my ¤0.02 worth.

 

[blue indigo]

That is likely very far from ideal.

Seconded. I find it rarely desirable to extend JFrame, rather than contain
one as a private instance field and provide my own show or similar methods
that delegate to it. Only if client code needs to be able to monkey with,
move, resize, etc. the JFrame in arbitrary ways does it make sense to
expose it. And even then, it's possible to supply a getter to return a
JFrame field.

Of course, my feelings about this tend to make me spend half the night
sometimes refactoring some code I have to maintain heavily. It's often not
even just class Foo extends JFrame; it's class Foo extends JFrame
implements ActionListener, WindowListener, MouseListener, and so forth,
complete with exposed public methods like actionPerformed that clients
should never call. Gag me with a spoon! There are special places you're
supposed to go if you want to let it all hang out in public; programmers
that write this particular kind of awful GUI code* probably ought to be
banished to them.

* As opposed to any of the numerous other kinds of awful GUI code, the
full list of which this post is too small to contain.

 

[Quentin Hargreaves]

Of course, my feelings about this tend to make me spend half the night
sometimes refactoring some code I have to maintain heavily. It's often not
even just class Foo extends JFrame; it's class Foo extends JFrame
implements ActionListener, WindowListener, MouseListener, and so forth,
complete with exposed public methods like actionPerformed that clients
should never call. Gag me with a spoon! There are special places you're
supposed to go if you want to let it all hang out in public; programmers
that write this particular kind of awful GUI code* probably ought to be
banished to them.

Starting with at least one programmer at Sun Microsystems, I suppose:

http://java.sun.com/javase/6/docs/a...l#actionPerformed(java.awt.event.ActionEvent)
http://java.sun.com/javase/6/docs/a...dded(javax.swing.event.TableColumnModelEvent)
http://java.sun.com/javase/6/docs/a...r.html#focusGained(java.awt.event.FocusEvent)
http://java.sun.com/javase/6/docs/a...l#stateChanged(javax.swing.event.ChangeEvent)
http://java.sun.com/javase/6/docs/a...l#actionPerformed(java.awt.event.ActionEvent)

and so on, and so forth.

 

[blue indigo]

Starting with at least one programmer at Sun Microsystems, I suppose:

http://java.sun.com/javase/6/docs/api/javax/swing/JComboBox.html#
actionPerformed(java.awt.event.ActionEvent)

Oh, dear God. Don't remind me. When I first saw one like that in the Swing
API I actually burst out laughing, then broke down. My co-workers still
think I may be slightly nuts, years later.

I mean, it's not like they didn't have inner classes in Java by the time
Swing was released. Argh!

 

[Quentin Hargreaves]

On Thu, 5623 Sep 1993 13:55:42 -0700, Quentin Hargreaves wrote:

Erm ... wtf? I'm pretty sure it was 22 Jan 2009.

Oh, dear God. Don't remind me. When I first saw one like that in the Swing
API I actually burst out laughing, then broke down. My co-workers still
think I may be slightly nuts, years later.

If you find that sort of thing amusing, you'll love The Daily WTF.
http://thedailywtf.com/

 

[blue indigo]

Erm ... wtf? I'm pretty sure it was 22 Jan 2009.
http://en.wikipedia.org/wiki/Eternal_September


If you find that sort of thing amusing, you'll love The Daily WTF.
http://thedailywtf.com/

Don't tempt me. I have this in my hosts file:

127.0.0.1 thedailywtf.com

It's been there since about one week after I originally discovered the
site. I put it there when I realized I'd spent much of the preceding 168
hours howling at the moon and none of it getting any productive work done,
and meanwhile a major deadline was fast approaching (isn't one always?).

 

[neuneudr]

(e-mail address removed) wrote: ....

Delegation is not an alternative to OOP. It works fine with OOP.


No. And Java does not support multiple inheritance.

Java supports multiple interface inheritance. Some OO languages
have no concept of implementation inheritance and support
multiple inheritance, so I think your statement needs
clarification.

"Java supports multiple interface inheritance, but does
not support multiple implementation-inheritance... And
implementation-inheritance has nothing to do with OO".

I *think* what the OP refers too is that the most
common (broken) complain about Java regarding inheritance
is that people cannot "reuse code" [sic] from several classes.

What these people want to do can easily be achieved by
using multiple interface inheritance and delegating the
calls to wrapped objects.

So delegation is not an alternative to OOP, but it can
be used to easily circumvent the "problems" of not having
multiple implementation-inheritance.

I *think* this is what the OP's question is about.

300K LOC project here with zero instance of the keywords
"abstract" and "protected" and where every single class
is final. It can be done, and it's actually done (and
sometimes enforced by guidelines and build scripts) in
several projects.

Once again it should be noted that James Gosling himself
expressed regret not having gone "pure interface", leaving
that ugly implementation-inheritance wart on the side
(that is an opinion of course, which just happens to match
the opinion of Java's creator

Direct link to the paragraph where James Gosling explains
how delegation can be used to fix implementation-inheritance
problems [sic]:

http://www.artima.com/intv/gosling34.html

B.V.:: Bill Venners: But by delegation, you do mean this
B.V.:: object delegating to that object without it being a subclass?

J.G.: James Gosling: Yes -- without an (concrete) inheritance
J.G.: hierarchy. Rather than subclassing, just use pure interfaces.
J.G.: It's not so much that class inheritance is particularly bad.
J.G.: It just has problems.

Java would actually have been more elegant without implementation
inheritance: no more "abstract" keywords, no more final/non-final
class distinction (they would all have been final).

Once again it's just an opinion.

But Java does support multiple inheritance and OO analysis/design
requiring multiple inheritance can be programmed in Java in a
very simple (and in my opinion very clean) way,

Driss

 

[Arne Vajhøj]

Java supports multiple interface inheritance. Some OO languages
have no concept of implementation inheritance and support
multiple inheritance, so I think your statement needs
clarification.

"Java supports multiple interface inheritance, but does
not support multiple implementation-inheritance...

I don't think we usually call interface implementation
for inheritance.

But that is just terminology - I of course agree with
what Java does and does not.

> And
> implementation-inheritance has nothing to do with OO".

Implementation inheritance is part of OO. Inheriting functionality
from abstract base classes is essential for OO.

300K LOC project here with zero instance of the keywords
"abstract" and "protected" and where every single class
is final. It can be done, and it's actually done (and
sometimes enforced by guidelines and build scripts) in
several projects.

You can always use a subset of Java.

But often abstract base classes makes things a lot easier.

Once again it should be noted that James Gosling himself
expressed regret not having gone "pure interface", leaving
that ugly implementation-inheritance wart on the side
(that is an opinion of course, which just happens to match
the opinion of Java's creator

Direct link to the paragraph where James Gosling explains
how delegation can be used to fix implementation-inheritance
problems [sic]:

http://www.artima.com/intv/gosling34.html

I know the interview.

I have always thought that he was more interested in
getting people to think over the problem than in telling
them "the one and only truth".

Arne

 

[Daniel Pitts]

I don't think we usually call interface implementation
for inheritance.

In a strictly OOAD, implementation is secondary to interface.

But that is just terminology - I of course agree with
what Java does and does not.


Implementation inheritance is part of OO. Inheriting functionality
from abstract base classes is essential for OO.

I wouldn't say essential. Inheriting interface is essential for OO,
easy code-reuse is essential for any practical project, OO or otherwise.
Inheriting implementation is only one way to enable code result.
Delegation is, in fact, another method for this. If you think about it,
implementation inheritance is little more than interface inheritance
plus optimized delegation.