 |
AppletTalk.com
Java discussions newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Irlan agous
Guest
|
 Posted: Thu Jun 09, 2005 11:38 am Post subject: 2 extends |
 |
|
Hello i want to extend from 2 classes lik
public class PatientImpl extends DataModel ,UnicastRemoteObject implements
PatientInterface throws RemoteExeption;
But this gives an error message, dfoes anyone knows how to solve this?
Thanks
|
|
| Back to top |
|
 |
Andrew Thompson
Guest
|
| Posted: Thu Jun 09, 2005 12:07 pm Post subject: Re: 2 extends |
|
|
On Thu, 9 Jun 2005 13:38:40 +0200, Irlan agous wrote:
| Quote: | Hello i want to extend from 2 classes ...
...
But this gives an error message, dfoes anyone knows how to solve this?
|
Try reading the group, rather than simply posting questions to it.
Here is a link to one of the answers given for the very previous
message thread to this group!
<http://groups.google.com.au/group/comp.lang.java.help/msg/755d22bee4b041ae?hl=en>
--
Andrew Thompson
http://www.PhySci.org/codes/ Web & IT Help
http://www.PhySci.org/ Open-source software suite
http://www.1point1C.org/ Science & Technology
http://www.LensEscapes.com/ Images that escape the mundane
|
|
| Back to top |
|
|
Bryce
Guest
|
| Posted: Thu Jun 09, 2005 1:25 pm Post subject: Re: 2 extends |
|
|
On Thu, 9 Jun 2005 13:38:40 +0200, "Irlan agous" <irlan345 (AT) msn (DOT) com>
wrote:
| Quote: | Hello i want to extend from 2 classes lik
public class PatientImpl extends DataModel ,UnicastRemoteObject implements
PatientInterface throws RemoteExeption;
But this gives an error message, dfoes anyone knows how to solve this?
|
No multiple inheritence in Java.
--
now with more cowbell
|
|
| Back to top |
|
|
Thomas G. Marshall
Guest
|
| Posted: Fri Jun 10, 2005 10:43 pm Post subject: Re: 2 extends |
|
|
Bryce coughed up:
| Quote: | On Thu, 9 Jun 2005 13:38:40 +0200, "Irlan agous"
wrote:
Hello i want to extend from 2 classes lik
public class PatientImpl extends DataModel ,UnicastRemoteObject
implements PatientInterface throws RemoteExeption;
But this gives an error message, dfoes anyone knows how to solve
this?
No multiple inheritence in Java.
|
{cough, cough}....except for interfaces.
--
Everythinginlifeisrealative.Apingpongballseemssmalluntilsomeoneramsitupyournose.
|
|
| Back to top |
|
|
Hal Rosser
Guest
|
| Posted: Sat Jun 11, 2005 4:31 am Post subject: Re: 2 extends |
|
|
Pehaps you may consider creating an instance variable of the 'other' class.
This approach is preferred in many cases. Composition is a good alternative
to multiple inheritance, and is preferred by some authors of the subject.
HTH
"Irlan agous" <irlan345 (AT) msn (DOT) com> wrote
| Quote: | Hello i want to extend from 2 classes lik
public class PatientImpl extends DataModel ,UnicastRemoteObject implements
PatientInterface throws RemoteExeption;
But this gives an error message, dfoes anyone knows how to solve this?
Thanks
|
|
|
| Back to top |
|
|
Tor Iver Wilhelmsen
Guest
|
| Posted: Sat Jun 11, 2005 6:18 am Post subject: Re: 2 extends |
|
|
"Thomas G. Marshall" <tgm2tothe10thpower (AT) replacetextwithnumber (DOT) hotmail.com> writes:
| Quote: | {cough, cough}....except for interfaces.
|
Or through inner classes and using methods instead of casting.
public class MyClass {
private MyOtherType myOtherTypePart = new MyOtherType() {
public void overriddenMethod() {
// Should access members of MyClass
// otherwise it's pointless
}
}
public MyOtherType asMyOtherType() {
return myOtherTypePart;
}
}
|
|
| Back to top |
|
|
The Wogster
Guest
|
| Posted: Sat Jun 11, 2005 2:34 pm Post subject: Re: 2 extends |
|
|
Irlan agous wrote:
| Quote: | Hello i want to extend from 2 classes lik
public class PatientImpl extends DataModel ,UnicastRemoteObject implements
PatientInterface throws RemoteExeption;
But this gives an error message, dfoes anyone knows how to solve this?
|
There are a few tricks, an Interface is one, an instance of the second
class is another, you could potentially combine both or create a new
class that Interfaces to both, as a child of neither.
However needing multiple inheritance usually means that something in the
initial class design is broken. Often it's from trying to create a
jack-of-all-classes combining a bunch of what should be unrelated stuff
into a single class.
It's like the goto, it's legal in C, but the only times I have seen it
used, were because someone had programmed themselves into a corner.
Once I rewrote a few lines and got rid of it, the other is still there
AFAIK, because the code was so fragile, nobody was stupid enough to want
to monkey with it, even the lead programmer would not touch it.
W
|
|
| Back to top |
|
|
Thomas G. Marshall
Guest
|
| Posted: Sun Jun 12, 2005 1:30 am Post subject: Re: 2 extends |
|
|
The Wogster coughed up:
| Quote: | Irlan agous wrote:
Hello i want to extend from 2 classes lik
public class PatientImpl extends DataModel ,UnicastRemoteObject
implements PatientInterface throws RemoteExeption;
But this gives an error message, dfoes anyone knows how to solve
this?
There are a few tricks, an Interface is one, an instance of the second
class is another, you could potentially combine both or create a new
class that Interfaces to both, as a child of neither.
However needing multiple inheritance usually means that something in
the initial class design is broken. Often it's from trying to create
a jack-of-all-classes combining a bunch of what should be unrelated
stuff into a single class.
|
I agree with this.
| Quote: | It's like the goto, it's legal in C, but the only times I have seen it
used, were because someone had programmed themselves into a corner.
|
{sounds of a brake screech, collision, and sound of wobbling hubcap...}
If by "programmed themselves into a corner" you mean something akin to
"couldn't find another way to solve the problem then to use goto", then your
experience is far different from mine in the last 20 years.
While there certainly have been cases where a goto was used when someone
could not design properly, the vast majority of the times I've seen goto
actually used were to /increase/ the clarity and maintainability of the
code. Not that they simply got stuck.
The cases I'm thinking of almost always involved a function where the exit
of the function required several things to happen. The goto was in these
cases a much clearer alternative to otherwise *horrible* contrivances. In
these cases, to say that this was done only because the author missed a
better non-goto way to design it is to imply that using goto is /always/ to
be avoided, and is simply incorrect.
| Quote: | Once I rewrote a few lines and got rid of it, the other is still there
AFAIK, because the code was so fragile, nobody was stupid enough to
want to monkey with it, even the lead programmer would not touch it.
W
|
--
"Gentlemen, you can't fight in here! This is the War Room!"
|
|
| Back to top |
|
|
The Wogster
Guest
|
| Posted: Sun Jun 12, 2005 2:18 am Post subject: Re: 2 extends |
|
|
Thomas G. Marshall wrote:
| Quote: | The Wogster coughed up:
Irlan agous wrote:
Hello i want to extend from 2 classes lik
public class PatientImpl extends DataModel ,UnicastRemoteObject
implements PatientInterface throws RemoteExeption;
But this gives an error message, dfoes anyone knows how to solve
this?
There are a few tricks, an Interface is one, an instance of the second
class is another, you could potentially combine both or create a new
class that Interfaces to both, as a child of neither.
However needing multiple inheritance usually means that something in
the initial class design is broken. Often it's from trying to create
a jack-of-all-classes combining a bunch of what should be unrelated
stuff into a single class.
I agree with this.
It's like the goto, it's legal in C, but the only times I have seen it
used, were because someone had programmed themselves into a corner.
{sounds of a brake screech, collision, and sound of wobbling hubcap...}
If by "programmed themselves into a corner" you mean something akin to
"couldn't find another way to solve the problem then to use goto", then your
experience is far different from mine in the last 20 years.
|
I'm just relating to my experiences, in C and C like languages (C++ and
Java) the goto is usually a result of needing a quick solution to a bad
code design. Last time I saw a goto that was justified it was in
Commodore Basic and that was over 20 years ago. I've written a lot of
code since then, and never found a need to design something that needed
a goto.
| Quote: | While there certainly have been cases where a goto was used when someone
could not design properly, the vast majority of the times I've seen goto
actually used were to /increase/ the clarity and maintainability of the
code. Not that they simply got stuck.
|
In my experience, needing gotos to clarify and make code maintainable,
means the code wasn't designed properly in the first place. Procedural
program design theories don't require it, and OOP should have made it
illegal (IMNSHO). When you have structures like if-elseif-else and case
statements, there are usually better ways of doing it.
| Quote: | The cases I'm thinking of almost always involved a function where the exit
of the function required several things to happen. The goto was in these
cases a much clearer alternative to otherwise *horrible* contrivances. In
these cases, to say that this was done only because the author missed a
better non-goto way to design it is to imply that using goto is /always/ to
be avoided, and is simply incorrect.
|
With languages that have richly designed looping and redirection
constructs, you shouldn't need the goto. I didn't say it was always to
be avoided, just that when you feel the need to use goto (except maybe
in Gee Whiz Basic), it's usually a pretty good indicator that the code
design is lacking.
W
|
|
| Back to top |
|
|
Thomas G. Marshall
Guest
|
| Posted: Sun Jun 12, 2005 4:32 am Post subject: Re: 2 extends |
|
|
The Wogster coughed up:
| Quote: | Thomas G. Marshall wrote:
While there certainly have been cases where a goto was used when
someone could not design properly, the vast majority of the times
I've seen goto actually used were to /increase/ the clarity and
maintainability of the code. Not that they simply got stuck.
In my experience, needing gotos to clarify and make code maintainable,
means the code wasn't designed properly in the first place.
|
This is a common notion from students. It should /not/ be a notion among
seasoned engineers.
| Quote: | Procedural program design theories don't require it, and OOP should
have made it illegal (IMNSHO).
|
It has nothing whatsoever to do with either discipline specifically, so such
a statement doesn't accomplish much. {shrug}
| Quote: | When you have structures like
if-elseif-else and case statements, there are usually better ways of
doing it.
|
"usually". This doesn't mean that the goto doesn't have significant value.
| Quote: | The cases I'm thinking of almost always involved a function where
the exit of the function required several things to happen. The
goto was in these cases a much clearer alternative to otherwise
*horrible* contrivances. In these cases, to say that this was done
only because the author missed a better non-goto way to design it is
to imply that using goto is /always/ to be avoided, and is simply
incorrect.
With languages that have richly designed looping and redirection
constructs, you shouldn't need the goto. I didn't say it was always
to be avoided, just that when you feel the need to use goto (except
maybe in Gee Whiz Basic), it's usually a pretty good indicator that
the code design is lacking.
|
No, this last statement is very much saying that it is "always to be
avoided". There is no "need", other than a "need" to produce the clearest
possible code, and to use anything in your arsenal to accomplish that.
I can tell you why you'd want to tell a student such a thing. I've taught
computer programming before in different venues; you tend to want to present
the goto in a dim light (if not ban it outright) with beginners because it
is often the very /first/ thing that a beginner considers. It's probably
because, to a beginner, control-flow within a program is more easily thought
of in terms of the branching instruction rather than a conditional/looping
construct as a whole.
However, if the mere presence of a goto is enough to make you think that the
design is lacking, then you've simply not allowed yourself to use it
properly, and as a result it's conceivable that some of your design may have
been morphed out of shape in an effort to avoid it. As long as it is used
with forethought and in a downward motion, the goto can be a fine way to
improve readability and maintainability, parTICULARLY if it builds a clear
section within a function for cleanup. Demonizing the usage of goto
accomplishes nothing. In fact, out of hand demonization of goto is
something you'll most often observe among junior engineers.
--
Whyowhydidn'tsunmakejavarequireanuppercaselettertostartclassnames....
|
|
| Back to top |
|
|
The Wogster
Guest
|
| Posted: Sun Jun 12, 2005 2:22 pm Post subject: Re: 2 extends |
|
|
Thomas G. Marshall wrote:
| Quote: | The Wogster coughed up:
Thomas G. Marshall wrote:
While there certainly have been cases where a goto was used when
someone could not design properly, the vast majority of the times
I've seen goto actually used were to /increase/ the clarity and
maintainability of the code. Not that they simply got stuck.
In my experience, needing gotos to clarify and make code maintainable,
means the code wasn't designed properly in the first place.
This is a common notion from students. It should /not/ be a notion among
seasoned engineers.
|
I've been working in this stuff for nearly a quarter century, and in
that time, I have seen a whole bunch of languages (FORTRAN, COBOL, HYPO,
JCL, BASIC, VisualBasic (a BASIC that wants to be Pascal when it grows
up  , Pascal, Assembler (I bet few people here have actually seen
370/Assembler, worked with 6502 and Z80 Assemblers myself), C, C++ and
Currently studying Java - which is why I am here.
| Quote: |
Procedural program design theories don't require it, and OOP should
have made it illegal (IMNSHO).
It has nothing whatsoever to do with either discipline specifically, so such
a statement doesn't accomplish much. {shrug}
|
I maintain that when you "need" goto, it's usually in a function or
method that is trying to do too many things, and that breaking it down
into smaller pieces will actually lead to a cleaner, more maintainable
construct that doesn't need the goto.
| Quote: |
When you have structures like
if-elseif-else and case statements, there are usually better ways of
doing it.
"usually". This doesn't mean that the goto doesn't have significant value.
The cases I'm thinking of almost always involved a function where
the exit of the function required several things to happen. The
goto was in these cases a much clearer alternative to otherwise
*horrible* contrivances. In these cases, to say that this was done
only because the author missed a better non-goto way to design it is
to imply that using goto is /always/ to be avoided, and is simply
incorrect.
|
"The exit of the function required several things to happen", this
sounds like a case of a function trying to do too much, and breaking it
down into separate functions, to do each thing, might work better
without needing goto everywhere. Functions (and to an even larger
extent classes) should be treated as a black box that does something,
and does it well. This makes it much easier to write a library or
package of reusable code. Reusable code is worth 10 times what new code
is, since it's already written, tested and debugged.
| Quote: |
With languages that have richly designed looping and redirection
constructs, you shouldn't need the goto. I didn't say it was always
to be avoided, just that when you feel the need to use goto (except
maybe in Gee Whiz Basic), it's usually a pretty good indicator that
the code design is lacking.
No, this last statement is very much saying that it is "always to be
avoided". There is no "need", other than a "need" to produce the clearest
possible code, and to use anything in your arsenal to accomplish that.
|
I'll grant you the second part of that statement, you need the clearest
possible code, but I have yet to see code with gotos sprinkled
throughout, that didn't need a lot of comments to explain what it was
trying to do. I also have yet to see such code that had those comments
in it, unless some poor sod (me more then once), had to take the time to
figure it out, and added the comments later on. I have seen where the
whole mess was commented out, because someone rewrote it, in a clearer,
more consise, manner. More then once, I have been the someone who
rewrote it.
| Quote: | I can tell you why you'd want to tell a student such a thing. I've taught
computer programming before in different venues; you tend to want to present
the goto in a dim light (if not ban it outright) with beginners because it
is often the very /first/ thing that a beginner considers. It's probably
because, to a beginner, control-flow within a program is more easily thought
of in terms of the branching instruction rather than a conditional/looping
construct as a whole.
|
Goto is often presented in a dim light, because it's easy to overuse it,
I once saw a 700 line program (Commodore BASIC) that contained around
400 gotos, it was cheaper and faster to rewrite the whole program, then
to figure out, what in Hades the original writer was trying to do, or
what he had been smoking when he wrote it.
W
| Quote: | However, if the mere presence of a goto is enough to make you think that the
design is lacking, then you've simply not allowed yourself to use it
properly, and as a result it's conceivable that some of your design may have
been morphed out of shape in an effort to avoid it. As long as it is used
with forethought and in a downward motion, the goto can be a fine way to
improve readability and maintainability, parTICULARLY if it builds a clear
section within a function for cleanup. Demonizing the usage of goto
accomplishes nothing. In fact, out of hand demonization of goto is
something you'll most often observe among junior engineers.
|
|
|
| Back to top |
|
|
Patricia Shanahan
Guest
|
| Posted: Sun Jun 12, 2005 8:27 pm Post subject: Re: 2 extends |
|
|
The Wogster wrote:
....
| Quote: |
I'll grant you the second part of that statement, you need the clearest
possible code, but I have yet to see code with gotos sprinkled
throughout, that didn't need a lot of comments to explain what it was
trying to do.
|
Do you feel the same way about code that has, say, one goto per hundred
thousand lines of code?
Patricia
|
|
| Back to top |
|
|
Thomas G. Marshall
Guest
|
| Posted: Sun Jun 12, 2005 8:59 pm Post subject: Re: 2 extends |
|
|
The Wogster coughed up:
| Quote: | Thomas G. Marshall wrote:
The Wogster coughed up:
|
....[rip]...
[regarding goto]...
| Quote: | Procedural program design theories don't require it, and OOP should
have made it illegal (IMNSHO).
It has nothing whatsoever to do with either discipline specifically,
so such a statement doesn't accomplish much. {shrug}
I maintain that when you "need" goto, it's usually in a function or
method that is trying to do too many things, and that breaking it down
into smaller pieces will actually lead to a cleaner, more maintainable
construct that doesn't need the goto.
|
A very common use for goto is an exit out of a nested loop in a language
without multilevel or labeled breaks. Would you accept or not accept that
as a perfectly reasonable usage of goto?
It is still not at all clear where you wish to draw the line, particularly
with the statement you made:
"The Wogster":
Procedural program design theories don't
require it, and OOP should have made it
illegal (IMNSHO).
Here's what's wrong with it:
1. That procedural or any other program design theories don't require
something is certainly of no issue. Once you have a while() construct, you
do not need the for(; loop, and once you have if/else, you do not need the
switch. Would you hence argue against the for() and switch? It's a
pointless statement.
2. The concepts of OO and procedural programming are entirely orthogonal to
whether or not a language contains a goto. It is applicable throughout both
paradigms, and has no specific impact to either.
Again, the /out-of-hand/ demonizing of goto is thus far without merit.
Demonizing the misuse of goto is certainly with merit, as is demonizing the
misuse of anything, but that is an entirely different exercise than what you
seem to be attempting.
Now don't get me wrong here: I /prefer/ the restricted goto within java
(downward only "labeled" or "named" break) to the unrestricted versions
found in C/C++, because I like the way the code looks as a result. But when
you have a language without such a downward goto, then using an unrestricted
goto in a careful downward fashion is perfectly fine, and railing against
its usage is outright silly.
--
"His name was Robert Paulson. His name was Robert Paulson. His name was
Robert Paulson..."
|
|
| Back to top |
|
|
Thomas G. Marshall
Guest
|
| Posted: Sun Jun 12, 2005 9:01 pm Post subject: Re: 2 extends |
|
|
Patricia Shanahan coughed up:
| Quote: | The Wogster wrote:
...
I'll grant you the second part of that statement, you need the
clearest possible code, but I have yet to see code with gotos
sprinkled throughout, that didn't need a lot of comments to explain
what it was trying to do.
Do you feel the same way about code that has, say, one goto per
hundred thousand lines of code?
|
I am attempting to determine where his line is drawn as well. Had I read
this post first, I would have responded here instead.
--
"His name was Robert Paulson. His name was Robert Paulson. His name was
Robert Paulson..."
|
|
| Back to top |
|
|
The Wogster
Guest
|
| Posted: Sun Jun 12, 2005 9:51 pm Post subject: Re: 2 extends |
|
|
Patricia Shanahan wrote:
| Quote: | The Wogster wrote:
...
I'll grant you the second part of that statement, you need the
clearest possible code, but I have yet to see code with gotos
sprinkled throughout, that didn't need a lot of comments to explain
what it was trying to do.
Do you feel the same way about code that has, say, one goto per hundred
thousand lines of code?
|
It depends on why the goto is there in the first place. Commonly goto's
are used by two groups of people:
1) Students who don't know better, and usually end up with code that has
more in common with pasta then with well designed code. It's usually a
horrible mess, that someone else ends up rewriting, because it's faster
to do that, then to try and figure out the code.
2) Old timers who learned the goto back in the days of COBOL, FORTRAN
AND BASIC, where it was often the only option, and can't get their
brains around the newer concepts, in more modern languages. These are
often the guys who did the flowchart after the code was done. They also
often write code that has the minimum number of comments allowed by
employer specifications.
W
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
