death by design pattern
billabyte
I'm new to java, and am working on my second java project. Both projects,
written by people who left the company I work at, make extensive use of
"design patterns". Having come from a 10-year procedural C programming
background, these patterns seem really odd to me. Objects seemed odd too,
and right after I got use to them, now I hear we are supposed to not really
use inheritance, but interfaces instead. These applications are massively
confusing to me, and the problems they are solving are not very complicated.
It's no wonder the projects are years late and way overbudget. I am
beginning to miss the old days of C.
I like Java because it has built in support for GUI's, easy thread support,
and is very cross-platform. However, the emphasis on design patterns is
souring my java experience. If the pay wasn't obscene, I'd go back to C.
My experience has been this. A company brings in (or has) some smart OOP
guys, they spend a few months drawing UML diagrams, and then they start
programming by creating the basic support for the design patterns they
identified. Since they are only ones who know what they are doing, they next
start bringing in all sorts of other technologies that they want to play
with. Finally, as the project nears it due date - they leave! Then the
company rounds up another batch of programmers to deal with what becomes
obvious is a clusterfuck created by the first group. The second group cant
figure out what the first group did, so they start over and also never
finish (blaming it on the first group, no less). The third group is
assembled around the remnants of the second group, who's junior programmers
are now the senior programmers of the third group. The third group manages
to hobble together a pattern-based system, which is now viewed as not
needed since customer demands have changed, but the company has to finish to
"save face".
The quest for the perfect OOP/design-pattern based-systems seems like a
company-killer. I hope debacles like the ones I've seen don't give Java a
reputation for being a black-hole for time and money. I hope I can either
"see the light" and appreciate design-patterns, or work on a project that
uses "normal java". I know Swing uses the MVC pattern, and I've done work
with "state-machines" - those "patterns" are fine with me. The Singleton I
don't see a need for, since I would prefer to create a class that was only
needed once during the initialization of the application - all that extra
code is only really there to support having ZERO instances of a class, which
makes no sense to me.
Anyway, what I want to know is - is this really the future of programming,
or a fad that I will be able to wait out?
Ben
UML diagrams and other "design patterns" (sounds like knitting) are
simplicity in themselves. If a developer can't take over from where another
left off by following properly drawn UML diagrams, in my opinion they
shouldn't be earning the kind of salary you suggest.
Design is a key part of any software project as any seasoned veteran
programmer will tell you, and with such huge projects we have today we need
OOP. The only way to accurately design and describe these systems is, you
guessed it, to use a Software Engineering approach. UML just happens to be
an industry standard.
If you've programmed any large software systems 500,000 lines plus, you'll
appreciate UML diagrams for what they are overviews to the parts of the
system you don't really need to know about but need to know how to use and
work.
When the software needs upgrading or changing 5 years later for new systems,
exapnsions etc. The first place of call will be diagrams. This saves a lot
of time and can be more accurate, since a developer merely looks up the part
to be changed carefully looking at the dependencies, instead of spending 6
months reading 500,000 lines of checking for them.
E.g plane control system. A change in engine specification might mean the
obvious, greater fuel consumption, increased thrust and speed etc. What
about other systems such as turning sheer, autopilot reaction times, fire
control systems operation etc.
</rant mode>
Chin up, its just going to get worse. From what you suggest the first
programmers only had a basic idea of UML or did a botched job of system
design This is only going to get worse as the lack of IT skills in the
industry is going to make very rich people out of individuals who have a
little knowledge of OOP, just because there is no-one else available.
Ben
"billabyte" <bill...@hotmail.com> wrote in message
news:tXVw6.58379$Q47.14...@news1.rdc1.tn.home.com...
Roedy Green
wrote or quoted :
>However, the emphasis on design patterns is
>souring my java experience.
The idea of design patterns is just to use a standard vocabulary and a
standard set of techniques for solving problems rather than
reinventing the wheel is some quirky way. The problem is the creators
of the design patterns were academics. They wanted to impress you with
how brilliant they were rather that explain in simple terms what these
things really were. There are other books besides the gang of four.
I have figured out some of them and written them up in plain language
in the Java glossary. That may help. See design patterns and follow
the links.
These things are really much simpler than they first appear.
After you understand them then go back and read the Design Patterns
book it makes a lot more sense.
-
For more detail, please look up the key words mentioned in this post in
the Java Glossary at:
http://mindprod.com/jgloss.html or http://209.153.246.39/jgloss.html
If you don't see what you were looking for, complain!
--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963
oxbow_lakes
It sounds like crossed wires are occurring between "Design
Patterns" and OOD to me. As Roedy says, the patterns described
in the gang of four book are inherently pretty simple.
<i>Factory</i>, <i>Strategy</i>, <i>Delegate</i>, <i>Proxy</i>,
<i>Observer-observable</i>, <i>Wrapper</i> etc etc are all
patterns that you would probably naturally use anyway. Half the
point of design patterns is that a programmer can convey how
he/she has done something by reference to one-word design
pattern names as opposed to waffling on for half an hour to the
confusion of others. There can be no doubt that Design Patterns
are a good thing.
<p>
The original poster mentioned a system designed using UML in
some appalling way - now the conversation is not about design
patterns (or even UML) but just design in general. If their
design is so appalling that no-one can understand it, it is
hardly the fault of the messenger (UML in this case) is it?
Especially given that I have seen UML used extremely sketchily
in many cases.
<p>
For my own preference I prefer to Component-ize any system that
I write to a coarser grain than the individual java classes -
that way, you can get a feel for the architecture of the system
as a whole. I find UML less useful as a design tool because:
<ul>
<li>I am not too familiar with it (and neither are any of my
comrades)
<li>I have found its use vague
<li>It seems to be used in non-standard ways a lot of the time
</ul>
None of these are the fault of UML itself. Having said that, any
system's documentation <i>should</i> have a full UML breakdown.
As the 2nd poster has said, you should be able to use this to
rebuild the system.
</html>
Tim Tyler
: My experience has been this. A company brings in (or has) some smart OOP
: guys, they spend a few months drawing UML diagrams, and then they start
: programming by creating the basic support for the design patterns they
: identified. Since they are only ones who know what they are doing, they next
: start bringing in all sorts of other technologies that they want to play
: with. Finally, as the project nears it due date - they leave! Then the
: company rounds up another batch of programmers to deal with what becomes
: obvious is a clusterfuck created by the first group. The second group cant
: figure out what the first group did, so they start over and also never
: finish (blaming it on the first group, no less). The third group is
: assembled around the remnants of the second group, who's junior programmers
: are now the senior programmers of the third group. The third group manages
: to hobble together a pattern-based system, which is now viewed as not
: needed since customer demands have changed, but the company has to finish to
: "save face".
I hate to say that I laughed at this story - since the subject matter is
very serious - but it must have been the way you delivered it.
Don't give up on UML and design patterns because you have a messy
new project on your hands, that you don't properly understand yet.
--
__________
|im |yler Try my latest game - it rockz - http://rockz.co.uk/
pete@nospam
OO is certinally a very powerfull and usefull programming methodology.
But it can be abused just like anything else.
I understand what you saying though. The concept of keeping it simple,
and common sense in programming seems to have gone out of the window.
I have been programming for 20 years, and have seen programmers spend
spend so much time on some trivial programs, becuase they get stuck
in their UML diagrams and writing 20 classes for what could be done
in 20 lines of code.
Thomas Holenstein
> Are design patterns really necessary?
> [...]
In contrast to many other follow ups i actually think you have a point
here. In my (not very experienced) opinion, some people tend to think
that heavy appliance of design patterns is good design. This is of
course wrong, as everyone will agree.
Design patterns serve IMHO two purposes:
- Make it as simple as possible, but not simpler.
- Be able to talk about the design.
Design patterns should make your code simpler, not more difficult. If
they make it more complicated you have bad design. You should however
know the patterns and their names, as this enables you to talk with
other people and understand a well documented design more quickly.
Awaiting flames... :-)
Thomas
Jarle Stabell
> "billabyte" <bill...@hotmail.com> writes:
>
> > Are design patterns really necessary?
> > [...]
>
> In contrast to many other follow ups i actually think you have a point
> here.
I think so too. And many others do the same. Some people seem to believe
that the more Design Patterns they've used in their code/design, the better.
That's a dangerous idea.
The original poster will probably find a lot to agree with in this article:
"Is Design Dead?"
http://www.sdmagazine.com/articles/2001/0104/0104a/0104a.htm
Cheers,
Jarle
billabyte
this thread.
I'm reading some more books on design patterns, reassuring myself that since
the State Machine is a valid concept, maybe the other patterns are too. Of
course I would have previously called a state machine an "algorithm", like a
quicksort or binary-search method. Maybe design patterns are just
algorithms renamed?
I like eXtreme Programming, I like it because its what I already do. I map
out all my memory structures up front (structs), but then I just start with
a tiny main function which I add complexity to. Adding complexity to a
stable app always makes it obvious where the problem is when something goes
wrong, because its usually the last thing you added. This idea of writing
all the parts ('objects') of the program then combining them with a
'pattern', only to then have 200-300 errors to fix - seems counterproductive
to me. I would rather fix things as I break them, not wait until I think I'm
done. What's embarrassing is when they pop all these pieces together, and
not only don't know where the problems are, but don't even know "what its
doing".
I know a lot of my issues with "design patterns" are really issues with my
company's methodologies, so I'm keeping at it - and trying to better
separate the two. My current feeling is that "patterns" are mostly an
OOP-related idea. Perhaps they are just "Algorithms for Objects". From
some of the responses here and via e-mail, it seems clear that there is
contingent of programmers who have not been overly impressed with "design
patterns" - treating them as just another tool, rather than a Holy Grail.
"Jarle Stabell" <ja...@dlogikk.com> wrote in message
news:20ix6.1039$CO5.1...@news01.chello.no...
kevin@nospam
says...
>
>I like eXtreme Programming, I like it because its what I already do. I map
>out all my memory structures up front (structs), but then I just start with
>a tiny main function which I add complexity to.
Ok. But this is not the best way to design software really.
It works for simple programs, but does not work for large programs.
The world is made of objects, not structs. instead of 'mapping' structs,
you should be thinking on objects.
>This idea of writing
>all the parts ('objects') of the program then combining them with a
>'pattern', only to then have 200-300 errors to fix - seems counterproductive
>to me.
The way I program, is that first I idenify the objects I need. I write classes
for those objects (I never at this time worry about the overall design,
becuase I know I need these small objects any way).
When I have all my objects designed, writing the program is trivial. It is
a matter of sending the right messages to the right objects, and the
objects do the hard work for me.
The nice thing about this, is that you can reuse many of these objects
in other programs.
You combine bottom up programming with OO programming.
I used to program like you before, and now I could never go back to
it. It is very unproductive way of programming and becomes hard to maintain
for large programs.
again, the first thing you do, is think what are the objects involved. Never
think about how they are represented in memory or any other such artifical
issues so early in the game.
WernerP
>
>Anyway, what I want to know is - is this really the future of programming,
>or a fad that I will be able to wait out?
Actually I agree partially. I once was in a project where the lead
designer/programmer was a pattern guru. The code was close to being
unreadable due to the massive amount of patterns this guy was using. He
almost took a pattern for every problem he encountered no matter if it
made sense and made the code more readable or not. Additionally to this
problem came the problem of non existing documentation in the code, so
you really had a problem to identify most patterns afterwards.
I personally think that patterns should be used whenever needed, but its
better to stick to the simpler patterns, cause they are more easy to
learn and understand and use the more complicated patterns only really
well documented (aka documentation references to the pattern). I
personally think the best would be to have a company wide consensous on
which patterns to use and have everybody who has to design and maintain
the code tought on these patterns heavily.
Werner
--
Memory Dragon
Q: Does EMACS have a Buddhist nature?
A: Sure, why not? It has everything else.
eugene aresteanu
Suppose you know nothing about design patterns. You will invent
them by yourself, not even knowing that you are an inventor!
And your fellow programmer will re-invent them again, with a
personal twist, of course! Your newly discovered "singleton pattern"
and his, will be slightly different, will be named differently and will
have each a fair amount of mistakes. Therefor, I am all in favour of
(at least) exposure to design patterns.
As for UML, I am not so sure at all. Someone said that it is easier to
see the whole picture by looking and rectangles and arrows rather than
reading vast amounts of code. First, you do not need to read vast
amounts of code. Specifically for Java, I'd rather read the JavaDoc
than look at UML.
eugene aresteanu
You can program in Java without UML and without design patterns,
if this is your very legitimate choice. Java, more than any other language,
brought self-documentation and desig patterns into the language itself.
UML and design patterns are excellent tools for assembler programmers,
since they supplement the total lack of expressivity and structure of
the language. I know I exagerate, but I am trying to make my point that
Java needs external help less, not more than other languages.
billabyte
> almost took a pattern for every problem he encountered no matter if it
> made sense and made the code more readable or not. Additionally to this
> problem came the problem of non existing documentation in the code, so
> you really had a problem to identify most patterns afterwards.
We have the same lack-of-documentation problem. We have tons of code with
almost ZERO internal documentation, when I asked WHERE the documentation
was, I was told it was in our version control software (PVCS), "Where it
should be" they said.
John Lockwood
wrote:
It's also not eXtreme programming, where one starts with the test
case.
John
gbp
>My experience has been this. A company brings in (or has) some
smart OOP
>guys, they spend a few months drawing UML diagrams, and then they
start
>programming by creating the basic support for the design patterns
they
>identified. Since they are only ones who know what they are doing,
they next
>start bringing in all sorts of other technologies that they want to
play
>with. Finally, as the project nears it due date - they leave!
I've been told this trick was around long before OOP!
Being a maintance programmer is hard. At least they left you
diagrams even if you are having trouble reading them.
I had the opposite experience last year. I was brought in to
replace someone who learned how to program 20 years ago. His stuff
worked but every variable was GLOBAL. This didn't seem to bother
him--- he had the ability to remember dozens of variables in his
head apparently. Needly to say this code would be considered "bad"
but just about every Java programmer (it was in Perl). However it
worked well and we did have time to rewrite it just because it would
have gotten a D in programming 101 :)
While your pouring through those OOP books trying to figure out what
they did get a book on maintaince programming that provides some
stratagies on how to extend existing code that is less than clear.
There is middle ground between starting over and being bound to
their OOP diagrams. The fastest way may be be cannablize there code
for the parts your find time saving and ignoring the parts you find
stupid. If it doesn't save you time why use it?
gbp
> Having come from a 10-year procedural C programming
>background, these patterns seem really odd to me. Objects seemed
odd too,
>and right after I got use to them, now I hear we are supposed to
not really
>use inheritance, but interfaces instead.
Well if the relation between Objects and "interfaces" doesn't seem
very "cutting edge advanced" to you its because its not.
Interfaces are kind of a Java kludge, because they didn't want to
add the complex (i.e. for the compiler writer) multipile inheritence
to the language. Inner classes are also a kludge.
Both interfaces and inner classes are highly useful though.
Interfaces are actually pretty simple while inner classes can be a
real pain. It may help to think of an interface as a second rate
abstract class. An interface can do some of what an abstract class
can. The abstract class is better than the interface. However,
java only lets you extend from one class at a time but you may
extend from as many interfaces as you like. Therefore you may need
to use interfaces depending on the rest of your program. If the old
programmer was "design happy" he may have used too many interfaces
because "interfaces are better" because they allow you to give
around the single inheritence limit-- and therefore your program
will be more "expandable". This is bulsh_t--- classes are often
better.
One "pattern" (not really a pattern because its just a simple
obvious thing) that people use to get around the problem that
interfaces are a second rate class is this: declare an interface,
then declare and abstart object the impliments the interface, THEN
declare one or more concrete classes that extend the abstract
object! This may have you tying your hair out if your new to OOP--
but its not a big deal, the Java API even does it.
This allows you to get around multiple inheritance (use the
interface) or to use the more functional classes (by extending the
abstract class).
gbp
>I have been programming for 20 years, and have seen programmers
spend
>spend so much time on some trivial programs, becuase they get stuck
>in their UML diagrams and writing 20 classes for what could be done
>in 20 lines of code.
When I was in college I've heard more than one professor say that
anything you can do in one screen (24 lines) of code is fair game.
Longer than that and you should break it into seperate functions (or
in java classes etc.). As a rule of thumb, they wouldn't penalize
you for writing unstructured code if it was less than 24 lines.
This was a big concern because they would take points away, if say
for example, you submitted a project in one source file insted of
splitting it into more than one-- even if you could argue that it
read better in one.
gbp
>We have the same lack-of-documentation problem. We have tons of
code with
>almost ZERO internal documentation, when I asked WHERE the
documentation
>was, I was told it was in our version control software (PVCS),
"Where it
>should be" they said.
Did they mean the documentation was version controlled or that there
was NO documentation :) Keeping the docs in the version control
system isn't a bad idea.
Roedy Green
or quoted :
>It may help to think of an interface as a second rate
>abstract class.
See "interface" and "abstract class" for the pros and cons of each.
gbp
>See "interface" and "abstract class" for the pros and cons of each.
>
>-
I know the pros and cons of the two. When I said interfaces were
second rate classes I meant that interfaces are not as good as
multiple inheritance (which of course java lacks).
Interfaces can not hold fields. They connot be concrete. They
cannot extend a class (only another interface). To impliment an
interface you must define every method (yes I know there is a
workaround pattern).
Interfaces remind of of something out of perl. Perl was a super
simple language that has been expanded (only half sucessfully) to
have lots of features it didn't origionally. The typical Perl
textbook has lots of sentences like this "Perl doesn't have feature
X but, feature X can be simulated by... [insert two cunfusing pages
here]" The typical intro to Java text has the sentence "Java
doesn't have multipile inheritence but some of the same
functionality can be gained from interfaces." I have more than one
book that suggests that this is somehow simpiler because we don't
have to learn any rules about multiple inheritance... as if we don't
have the learn interfaces either. Sun seems to have an official
explanation the interfaces are better than multipile inheritance
which is just crazy to me.
Every good langauge has 1-2 problems, there is no perfect langauge I
can live with interfaces, but I don't have to like them :)
Other big complaint: no unsigned integer types! Sun's reason:
makes the langauge "simpler". These would be usefull in any kind of
low level programming... leaving them out makes little sense!
Roedy Green
or quoted :
>>See "interface" and "abstract class" for the pros and cons of each.
>I know the pros and cons of the two.
Interfaces even have some advantages over multiple inheritance.
gbp
>
>Interfaces even have some advantages over multiple inheritance.
>
I read the entry for interface. I still don't see the advantage over
multiple inheritence.
Let me give you an example of where you might want to use multiple
inheritence. Lets say your writing an app for a college setting.
You have a Student Class and you have a Teacher Class You also have
your Person Class (because everyones got a name sex etc.) Student
and Teacher both have Person as their Super Class. So far you can
do this in Java. Now lets say just for kicks a year passes. You
are asked to add code that relates to TA's. Now being a good OOP
program you make a new class the inherites from both Teacher and
Student because TAs are in the strange position of being both.
Now if your using Java what do you do? the answer is sure you can
do this but its not going to be pretty. I think the best you can do
is make your TA a new class that has-a teacher and has-a student
object. At least this way you can use your existing methods that
take and return Teacher and Student Objects. You really need to do
this unless you think rewriting and retesting code is a good use of
your time.
So I guess my major problem with interfaces is that sometimes you
don't know in advance that you want to use 'multiple inheritence' so
you don't know when to use the interface insted of a class. On the
other hand you can't just make everything interfaces because then
you loss a lot of the functionality that objects provide when they
use inheritence.
Jim Sculley
>
> >See "interface" and "abstract class" for the pros and cons of each.
> >
> >-
>
> I know the pros and cons of the two. When I said interfaces were
> second rate classes I meant that interfaces are not as good as
> multiple inheritance (which of course java lacks).
Saying it doesn't necessarily make it true.
>
> Interfaces can not hold fields.
This a would depend on your definition of Field. To be 100% accurate,
you would have to say that an Interface cannot hold a variable. They
are perfectly capable of holding fields. See ActivationSystem,
Adjustable, AttributeSet, BeanContext, BeanInfo, CharacterIterator,
Connection, DatabaseMetaData, DesignMode, Document, DSAPrivateKey,
DSAPublicKey, DTDConstants, EndPoint, ImageConsumer, ImageObserver,
JPEGDecodeParam, Key, ListSelectionModel, LoaderHandler, Member,
ObjectStreamConstants, OpenType, Pageable, PathIterator, Position,
Printable, PrivateKey, PublicKey, RemoteRef, Registry, RenderableImage,
ResultSet, ResultSetMetaData, RTFAttribute, ScrollPaneConstants,
ServerRef, ServerSubcontract, SocketOptions, StateEditable,
SwingConstants, TGConstants, Transparency, TreeSelectionModel,
WindowConstants, WindowPeer, and ZipConstants.
To name a few.
> They connot be concrete.
Nor would it make sense for them to be concrete, since their primary
purpose is abstraction. Interfaces aren't second rate classes, they are
a parallel concept. The highest entity in Java is the 'Type'. Classes
and Interfaces are both 'Types'.
> They cannot extend a class (only another interface).
See above.
> To impliment an interface you must define every method (yes I know there is a
> workaround pattern).
Then saying 'you must define every method' is incorrect? See
XXXAdapter. I'm sure the Gang Of Four would like to hear your reasoning
for reclassification of 'Adapter' to 'Workaround'.
>
> Interfaces remind of of something out of perl. Perl was a super
> simple language that has been expanded (only half sucessfully) to
> have lots of features it didn't origionally.
Since interfaces have been part of Java from Day One, I don't see how
the above statement is relevant.
<snip>
> Sun seems to have an official explanation the interfaces are better than multipile
> inheritance which is just crazy to me.
http://java.sun.com/docs/white/langenv/Simple.doc2.html#4090
"Multiple inheritance--and all the problems it generates--was discarded
from Java. The desirable features of multiple inheritance are provided
by interfaces--conceptually similar to Objective C protocols."
There was a lengthy discussion a while back about multiple inheritance
involving a stove if I recall correctly. Too bad Deja is sick, or I
would point you to the thread. Interesting discussion. I don't recall
the pro-MI individual winning the debate.
<snip>
> Other big complaint: no unsigned integer types! Sun's reason:
> makes the langauge "simpler". These would be usefull in any kind of
> low level programming... leaving them out makes little sense!
Unless the language isn't meant for low-level programming. Which it
isn't.
Jim S.
David Glass
>
> Interfaces even have some advantages over multiple inheritance.
>
Sure, interfaces can be useful, but if a language has (well-implemented)
multiple inheritance and abstract classes, it has all the power of
interfaces and more.
oxbow_lakes
like to explain how it would be better to have
<i>ActionListener, EventListener etc etc</i> as abstract classes
as opposed to interfaces? Interfaces are a fundamental design
pattern and have been built in to the Java language because they
are so useful - in my opinion the fact that they solve the
multiple inheritance problem is merely a side issue.
<p>
Suppose (I'm talking to you, <b>gbp</b>) that you are
implementing a program which makes extensive use of Collections
(what doesn't?). At first you use the <i>java.util</i>
Collection classes (NB <b>not</b> interfaces) framework because
it is there - but this turns out to be inadequate for whatever
reason (maybe it doesn't scale well, or isn't as performant as
you'd like for another reason) and you want to switch to a set
of custom-written collections. If you merely had abstract
classes (no interfaces) you'd have run into a nightmare of
picking thru code doing search and replace.
<p>
But you weren't so daft - you used the <i>java.util</i>
Collection <b>interfaces</b>. And used a <i>Factory</i> object
to return implementations of these interfaces
(<tt>CollFactory.newSet()</tt>, <tt>CollFactory.newMap()</tt>,
<tt>CollFactory.newList()</tt> etc etc) in your code. Using
interfaces has given you the ability to define your collection
implementations in ONE PLACE - thus removing interface from
implementation almost completely. You can now develop your own
Collection classes as you wish, make them implement the relevant
interfaces from <i>java.util</i> and change only ONE class (the
Factory) to completely change your application. Whew - you're
glad you used interfaces and not those dastardly abstract
classes for this aren't you?
<p>
Or maybe you're not and you can just carry on making dubious,
uninformed ("I've thought about it" - oh yeah? For more than 5
seconds?) remarks. If you're so hot on OO - go and check out
Smalltalk instead of C++ - that'll give you some idea about
proper design.
</html>
none
wrote:
>gbp wrote:
>>
>> >See "interface" and "abstract class" for the pros and cons of each.
>> >
>> >-
>>
>> I know the pros and cons of the two. When I said interfaces were
>> second rate classes I meant that interfaces are not as good as
>> multiple inheritance (which of course java lacks).
>
>Saying it doesn't necessarily make it true.
Saying saying it doesn't necessarily make it true doesn't necessarily
make it untrue either.
Great debating technique!
>>
>> Interfaces can not hold fields.
>
>This a would depend on your definition of Field. To be 100% accurate,
>you would have to say that an Interface cannot hold a variable.
That would be the traditional definition. And it's true, right?
>There was a lengthy discussion a while back about multiple inheritance
>involving a stove if I recall correctly. Too bad Deja is sick, or I
>would point you to the thread. Interesting discussion. I don't recall
>the pro-MI individual winning the debate.
He probably made statements like "saying it doesn't necessarily make
it so".
______________________________________________________________________
Posted Via Uncensored-News.Com - Still Only $9.95 - http://www.uncensored-news.com
With Seven Servers In California And Texas - The Worlds Uncensored News Source
none
C++'s advanced features, such as MI. Even pointers blow a lot of
people away.
none
That's the problem. Most people who call themselves "programmers"
can't handle the power, thus they criticize it. Many of them don't
even understand pointers or double-indirection. Their brains just
aren't wired for it.
Mark Smith
>Maybe he'd
>like to explain how it would be better to have
>ActionListener, EventListener etc etc as abstract classes
>as opposed to interfaces?
Actually, Microsoft's evil delegates were a much better solution
for things like ActionListener. Being forced to subclass a
specifically named interface and implement a specifically named
method is overkill when all that's really needed is some method
in some class method with the appropriate type signature.
>Interfaces are a fundamental design
>pattern and have been built in to the Java language because they
>are so useful - in my opinion the fact that they solve the
>multiple inheritance problem is merely a side issue.
They don't solve the problem, they just work around it, with
varying degrees of success.
Mark Smith
>method is overkill when all that's really needed is some method
>in some class method with the appropriate type signature.
Oops, strike "method" in the last line above.
oxbow_lakes
Sounds an awful lot like the original Java 1.0 event model - and
all very OO that was ;-)
<p>
It's certainly true that I am not familiar with using multiple
inheritance to solve problems such as the one I mentioned
earlier (which would have not been a problem in a weakly-typed
language anyway). I messed up my wording about
interfaces "solving" MI for Java - I know that they don't from
the point of view of still having to write an extra bit of code,
but as an end-result they effectively can "mimic" (a better
word) the desired behaviour and in a much clearer way.
<p>
As for the previous guy saying we "don't understand pointers or
double-indirection", well that's cos I don't need to - pointers
aren't part of the Java language and I haven't a clue what the
last thing is (Unless it's a fancy way of saying MI). Maybe
you'd like to try and make a point relevant to the discussion
next time - just because you've been breast-fed C++ until you're
dreaming about Stroustrup doesn't mean that no-one who doesn't
understand C++ language concepts is a moron (right? - I mean, I
suspect you don't understand the Japanese language structure but
it doesn't make <i>you</i> a moron) - if it were so great, why
is it practically every new piece of server-side software
development in things like Web/Component/n-tier/etc/etc -based
systems being done in Java (this is my experience)? Actually,
don't answer that one - I've met Project managers too ;-)
<p>
Konnidjy-wah!
<p>
Mr.Mori.
</html>
Jim Sculley
>
> On Tue, 03 Apr 2001 08:04:53 -0400, Jim Sculley <nic...@abraxis.com>
> wrote:
>
> >gbp wrote:
> >>
> >> >See "interface" and "abstract class" for the pros and cons of each.
> >> >
> >> >-
> >>
> >> I know the pros and cons of the two. When I said interfaces were
> >> second rate classes I meant that interfaces are not as good as
> >> multiple inheritance (which of course java lacks).
> >
> >Saying it doesn't necessarily make it true.
>
> Saying saying it doesn't necessarily make it true doesn't necessarily
> make it untrue either.
>
> Great debating technique!
Excellent grammar!
Nice snipping Jen. Good job ignoring the entire content of of my post.
>
> >>
> >> Interfaces can not hold fields.
> >
> >This a would depend on your definition of Field. To be 100% accurate,
> >you would have to say that an Interface cannot hold a variable.
>
> That would be the traditional definition.
Traditional? Hardly. A constant Field is still a Field. The terms
Field and variable are not interchangeable. Anyone who has read the
Java Language Specification knows that such terms are explicity defined
with respect to Java. And per the JLS, interfaces can have fields.
> And it's true, right?
No. See above.
Jim S.
Jorn W Janneck
"Jim Sculley" <nic...@abraxis.com> wrote in message
news:3AC9BC65...@abraxis.com...
> gbp wrote:
> >
> > >See "interface" and "abstract class" for the pros and cons of each.
> > >
> > >-
> >
> > I know the pros and cons of the two. When I said interfaces were
> > second rate classes I meant that interfaces are not as good as
> > multiple inheritance (which of course java lacks).
>
> Saying it doesn't necessarily make it true.
>
> >
> > Interfaces can not hold fields.
>
> This a would depend on your definition of Field. To be 100% accurate,
> you would have to say that an Interface cannot hold a variable. They
> are perfectly capable of holding fields. See ActivationSystem,
> Adjustable, AttributeSet, BeanContext, BeanInfo, CharacterIterator,
> Connection, DatabaseMetaData, DesignMode, Document, DSAPrivateKey,
> DSAPublicKey, DTDConstants, EndPoint, ImageConsumer, ImageObserver,
> JPEGDecodeParam, Key, ListSelectionModel, LoaderHandler, Member,
> ObjectStreamConstants, OpenType, Pageable, PathIterator, Position,
> Printable, PrivateKey, PublicKey, RemoteRef, Registry, RenderableImage,
> ResultSet, ResultSetMetaData, RTFAttribute, ScrollPaneConstants,
> ServerRef, ServerSubcontract, SocketOptions, StateEditable,
> SwingConstants, TGConstants, Transparency, TreeSelectionModel,
> WindowConstants, WindowPeer, and ZipConstants.
>
> To name a few.
sure, but you know what he meant, so.
> > They connot be concrete.
>
> Nor would it make sense for them to be concrete, since their primary
> purpose is abstraction.
the primary purpose of classes is abstraction, i do not see how the
inability to instantiate interfaces (and of course you are right, it doesn't
make sense to instantiate them, as there is nothing to instantiate) is
related to their purpose to facilitate abstraction.
> Interfaces aren't second rate classes, they are
> a parallel concept.
i don't really think so. interfaces are equivalent to fully abstract
classes, with the added resriction that they may only extend other
interfaces. they are by no means orthogonal to classes, not even from a
language point of view: reflection treats them as classes, they are stored
the way classes are, and i think any semantic theory would treat them as
(fully abstract) classes.
the fact that they may contain fields only underpins this.
> The highest entity in Java is the 'Type'. Classes
> and Interfaces are both 'Types'.
sure. but that is just juggling words. except for a few restrictions on
inheritance (which are basically driven by implementation concerns and maybe
by a wish to simplify the language), interfaces appear as abstract classes.
> > They cannot extend a class (only another interface).
>
> See above.
i think the original poster felt that anything you could do with interfaces
you could do with multiple inheritance of fully abstract classes. i think he
is right.
[snip]
> > Sun seems to have an official explanation the interfaces are better than
multipile
> > inheritance which is just crazy to me.
>
> http://java.sun.com/docs/white/langenv/Simple.doc2.html#4090
>
> "Multiple inheritance--and all the problems it generates--was discarded
> from Java. The desirable features of multiple inheritance are provided
> by interfaces--conceptually similar to Objective C protocols."
that is 'desirable' in the eyes of the java designers. if all you got is a
hammer...
> There was a lengthy discussion a while back about multiple inheritance
> involving a stove if I recall correctly. Too bad Deja is sick, or I
> would point you to the thread. Interesting discussion. I don't recall
> the pro-MI individual winning the debate.
there is really no 'winning' of this debate. it's like the operator
overloading debate -- one side claims it's a nicer language design,
convenient, more orthogonal, and that there is no difference between
misusing the operator + for formatting the harddrive or calling that same
functionality 'add()', and the other side says it's dangerous, people will
be misusing it, you hardly ever need it anyway, and that the wisdom of the
language designers fortunately excluded it/should have excluded it. that's
the debate. it's the same for mi, operator overloading, parametric
polymorphism, and other things that java does not have. ;-)
best regards,
-- j
Jorn W Janneck
"oxbow_lakes" <%5flakesNO%5S...@sun.partner.remarq.com.invalid> wrote in
message news:00000005...@usw-ex0108-190.remarq.com...
> <html>Thanks for getting to <b>gbp</b> before me. Maybe he'd
> like to explain how it would be better to have
> <i>ActionListener, EventListener etc etc</i> as abstract classes
> as opposed to interfaces? Interfaces are a fundamental design
> pattern and have been built in to the Java language because they
> are so useful - in my opinion the fact that they solve the
> multiple inheritance problem is merely a side issue.
> <p>
> Suppose (I'm talking to you, <b>gbp</b>) that you are
> implementing a program which makes extensive use of Collections
> (what doesn't?). At first you use the <i>java.util</i>
> Collection classes (NB <b>not</b> interfaces) framework because
> it is there - but this turns out to be inadequate for whatever
> reason (maybe it doesn't scale well, or isn't as performant as
> you'd like for another reason) and you want to switch to a set
> of custom-written collections. If you merely had abstract
> classes (no interfaces) you'd have run into a nightmare of
> picking thru code doing search and replace.
i think you need to explain this -- why could you not do the exactly same
thing with abstract classes and multiple inheritance?
> <p>
> But you weren't so daft - you used the <i>java.util</i>
> Collection <b>interfaces</b>. And used a <i>Factory</i> object
> to return implementations of these interfaces
> (<tt>CollFactory.newSet()</tt>, <tt>CollFactory.newMap()</tt>,
> <tt>CollFactory.newList()</tt> etc etc) in your code. Using
> interfaces has given you the ability to define your collection
> implementations in ONE PLACE - thus removing interface from
> implementation almost completely. You can now develop your own
> Collection classes as you wish, make them implement the relevant
> interfaces from <i>java.util</i> and change only ONE class (the
> Factory) to completely change your application. Whew - you're
> glad you used interfaces and not those dastardly abstract
> classes for this aren't you?
> <p>
> Or maybe you're not and you can just carry on making dubious,
> uninformed ("I've thought about it" - oh yeah? For more than 5
> seconds?) remarks. If you're so hot on OO - go and check out
> Smalltalk instead of C++ - that'll give you some idea about
> proper design.
> </html>
thought it wouldn't help discussing multiple inheritance -- for this i would
rather point to eiffel. since you sound so knowledgable in the above
paragraph, you will probably be able to tell me why in eiffel (which does
not have interfaces but 'only' classes and mi) you could not do what you
described previously.
best regards,
-- j
Mark Smith
>Sounds an awful lot like the original Java 1.0 event model - and
>all very OO that was ;-)
You have to apply OO judiciously, not blindly. There are some
instances where a full-blown interface is unnecessarily restrictive.
Sorting is a good example -- all a sorting algorithm needs is a
function that can compare two objects and return whether one is
greater, less than or equal to the other. This is exactly what the
standard C library qsort() does. You gain nothing by being forced
to subclass a specific interface and give your comparison method a
specific name just to get the same functionality in an OO language.
That's the case where Microsoft's delegates were an elegant solution.
They let you bind based solely on a type signature when that was all
that was needed.
John Lockwood
text, not HTML.
On Tue, 03 Apr 2001 07:30:38 -0700, oxbow_lakes
<%5flakesNO%5S...@sun.partner.remarq.com.invalid> wrote:
><html>Thanks for getting to <b>gbp</b> before me.
<snip>
pete@-
>
>While we're on the subject of proper design, usenet typically uses
>text, not HTML.
>
know these things.
oxbow_lakes
Jorn W Janneck wrote:
<pre>
> i think you need to explain this -- why could you not do the
> exactly same
> thing with abstract classes and multiple inheritance?
As I said, I'm not too sure about the ins and outs of MI - so
I'll defer to you - but I never complained about whether you
<i>could</i> do it with MI, it just seems to me to be a less
elegant solution to the problem - why force inheritance when it
is not needed, MI seems (from the outside) like an overly
complicated way of doing something inherently simple? My
experience of OOP (learned from senior guys that I had a lot of
respect for) was that implementation details should be removed
from the "objects" passed around as much as possible. In
Smalltalk this is easy, as the language is weakly typed so you
can send any message to anything. Building interfaces into a
language seems to me like a great idea because it gives you a
way of representing fundamental OO concepts. So why use abstract
classes when they forec implementation details on you?
<p>
<pre>
>thought it wouldn't help discussing multiple inheritance --
>for this i would rather point to eiffel. since you sound so
>knowledgable in the above paragraph, you will probably be able
>to tell me why in eiffel (which does not have interfaces
>but 'only' classes and mi) you could not do what you
>described previously.
OK, OK - I've been rumbled - I've never seen eiffel. This
drawback makes me unqualified so have any opinions on the Java
language, or whether interfaces are "stoopid" and I shan't make
them again, lest I get sarky comments (which are emotionally
troubling to me) from the likes of you.
</html>
Jim Sculley
<snip>
> >
> > To name a few.
>
> sure, but you know what he meant, so.
No, I did not 'know' what 'gbp' meant. I've watched 'gbp' make a number
of vague and/or inaccurate technical statements in the other c.l.j.*
groups. I felt it was necessary to question the statement about
interfaces not holding fields.
>
> > > They connot be concrete.
> >
> > Nor would it make sense for them to be concrete, since their primary
> > purpose is abstraction.
>
> the primary purpose of classes is abstraction, i do not see how the
> inability to instantiate interfaces (and of course you are right, it doesn't
> make sense to instantiate them, as there is nothing to instantiate) is
> related to their purpose to facilitate abstraction.
The opposite of concrete is abstract. That is the point I was making.
Saying that an interface is a second rate class because it cannot be
concrete is a flawed statement. You may as well call abstract (fully or
otherwise) classes 'second class' for the same reason. I consider
classes to be an abstraction of reality, whereas interfaces are an
abstraction of classes. Abstract classes lie somewhere in between.
>
> > Interfaces aren't second rate classes, they are
> > a parallel concept.
>
> i don't really think so. interfaces are equivalent to fully abstract
> classes, with the added resriction that they may only extend other
> interfaces. they are by no means orthogonal to classes,
And the added benefit that a single class may implement many of them.
Note I said 'parallel', not orthogonal. In Java, the interface provides
some flexibility that doesn't exist with classes, even fully abstract
ones. You may argue that this is a 'limitation' when compared to other
languages, but such comparisons aren't very useful. If the original
poster was calling interfaces second rate classes in the context of
discussing the concept of classes as a whole (i.e. not within the
context of Java), then the argument may hold more water. It is not
clear that this is what was meant.
> not even from a
> language point of view: reflection treats them as classes, they are stored
> the way classes are, and i think any semantic theory would treat them as
> (fully abstract) classes.
Or perhaps the language, the VM and Reflection deal with Types. Note
that the JLS and the JVMS tend to avoid lumping the two concepts (class
and interface) together. At times I wish they had used the term 'Type'
more often, as it would eliminate some areas of confusion.
>
> the fact that they may contain fields only underpins this.
>
> > The highest entity in Java is the 'Type'. Classes
> > and Interfaces are both 'Types'.
>
> sure. but that is just juggling words. except for a few restrictions on
> inheritance (which are basically driven by implementation concerns and maybe
> by a wish to simplify the language), interfaces appear as abstract classes.
Except for the multiple implementation bit. Perhaps fully abstract
classes are merely interfaces with the added restriction that several
cannot be subclassed by a single class. It all depends on the end from
which you approach it.
>
> > > They cannot extend a class (only another interface).
> >
> > See above.
>
> i think the original poster felt that anything you could do with interfaces
> you could do with multiple inheritance of fully abstract classes. i think he
> is right.
I doubt anyone would disagree. However, I don't pretend to know what the
original poster 'felt' about anything. I can only read what was written
and comment on that. To call Interfaces 'second rate classes' hardly
seems equivalent to the statement 'anything you can do with interfaces
can be done with multiple inheritance of fully abstract classes'. Not
to me anyway.
<snip>
> > "Multiple inheritance--and all the problems it generates--was discarded
> > from Java. The desirable features of multiple inheritance are provided
> > by interfaces--conceptually similar to Objective C protocols."
>
> that is 'desirable' in the eyes of the java designers. if all you got is a
> hammer...
Well, when you create your own language, feel free to do with it as you
see fit. I cannot fault Sun for doing more than I am capable of doing
myself. Were some corners cut? Probably. Were some bad decisions
made? Certainly. But is the end result all that terrible? I don't
think so. I prefer to use the tools in the way they were intended to be
used. If the tool isn't meant to tighten bolts, no sense in complaining,
since there are other tools that are capable of doing the job. However,
since I unwrapped my Java toolbox, I haven't had much need to use the
others out there. Except for a smattering of JNI with the Win32 API,
which I find somewhat painful.
>
> > There was a lengthy discussion a while back about multiple inheritance
> > involving a stove if I recall correctly. Too bad Deja is sick, or I
> > would point you to the thread. Interesting discussion. I don't recall
> > the pro-MI individual winning the debate.
>
> there is really no 'winning' of this debate. it's like the operator
> overloading debate -- one side claims it's a nicer language design,
> convenient, more orthogonal, and that there is no difference between
> misusing the operator + for formatting the harddrive or calling that same
> functionality 'add()', and the other side says it's dangerous, people will
> be misusing it, you hardly ever need it anyway, and that the wisdom of the
> language designers fortunately excluded it/should have excluded it. that's
> the debate. it's the same for mi, operator overloading, parametric
> polymorphism, and other things that java does not have. ;-)
It is as winnable as the 'where should my braces go' debate. But if it
were winnable, what fun would it be? The past discussion on this was
pretty comprehensive. I wish I could go back and review it, since it
held a great deal of useful information. And probably some first rate
name-calling.
Jim S.
Rob Eamon
><html>
>Jorn W Janneck wrote:
><pre>
>> i think you need to explain this -- why could you not do the
>> exactly same
>> thing with abstract classes and multiple inheritance?
></pre><p>
>As I said, I'm not too sure about the ins and outs of MI - so
>I'll defer to you - but I never complained about whether you
><i>could</i> do it with MI, it just seems to me to be a less
>elegant solution to the problem - why force inheritance when it
>is not needed, MI seems (from the outside) like an overly
>complicated way of doing something inherently simple? My
>experience of OOP (learned from senior guys that I had a lot of
>respect for) was that implementation details should be removed
>from the "objects" passed around as much as possible. In
>Smalltalk this is easy, as the language is weakly typed so you
>can send any message to anything. Building interfaces into a
>language seems to me like a great idea because it gives you a
>way of representing fundamental OO concepts. So why use abstract
>classes when they forec implementation details on you?
Interfaces are essentially abstract (pure virtual) classes.
Being able to implement multiple interfaces provides
MI in Java. The downside to this in Java is that you don't
get to provide default implemenations for methods where
it makes sense. But at least there's still the method name
collision problem ;-)
Interfaces aren't more "elegant" than inheriting from
abstract classes. For all practical purposes, interfaces
are a form of inheritance.
Jorn W Janneck
"oxbow_lakes" <%5flakesNO%5S...@sun.partner.remarq.com.invalid> wrote in
message news:0000001c...@usw-ex0108-190.remarq.com...
> <html>
> Jorn W Janneck wrote:
> <pre>
> > i think you need to explain this -- why could you not do the
> > exactly same
> > thing with abstract classes and multiple inheritance?
> </pre><p>
> As I said, I'm not too sure about the ins and outs of MI - so
> I'll defer to you - but I never complained about whether you
> <i>could</i> do it with MI, it just seems to me to be a less
> elegant solution to the problem - why force inheritance when it
> is not needed, MI seems (from the outside) like an overly
> complicated way of doing something inherently simple?
i think from an mi pov, implementing an interface *is* only a special case
of mi, and interfaces *are* only special cases of classes, thus you could
ask the same question in reverse: why introduce a special syntax and 'new'
concepts for this special case? the answer, imo, is that this special case
coincides with a class of things you can easily implement without having to
worry about all the issue that arise from inheritance of implementation from
various sources (ignoring the issues that arise from inheritance of several
overlapping interfaces).
> My
> experience of OOP (learned from senior guys that I had a lot of
> respect for) was that implementation details should be removed
> from the "objects" passed around as much as possible. In
> Smalltalk this is easy, as the language is weakly typed so you
> can send any message to anything. Building interfaces into a
> language seems to me like a great idea because it gives you a
> way of representing fundamental OO concepts. So why use abstract
> classes when they forec implementation details on you?
i still do not understand why the use of abstract classes does this (force
implementation details on me) -- the point about mi with abstract classes vs
interfaces is that in abstract classes the implementer can choose precisely
how much implementation he or she would like to make inheritable.
> >thought it wouldn't help discussing multiple inheritance --
> >for this i would rather point to eiffel. since you sound so
> >knowledgable in the above paragraph, you will probably be able
> >to tell me why in eiffel (which does not have interfaces
> >but 'only' classes and mi) you could not do what you
> >described previously.
> </pre><p>
> OK, OK - I've been rumbled - I've never seen eiffel. This
> drawback makes me unqualified so have any opinions on the Java
> language, or whether interfaces are "stoopid" and I shan't make
> them again, lest I get sarky comments (which are emotionally
> troubling to me) from the likes of you.
sorry, but it seemed in line with the tone of your paragraph to the previous
poster, quoted here for your convenience:
> Or maybe you're not and you can just carry on making dubious,
> uninformed ("I've thought about it" - oh yeah? For more than 5
> seconds?) remarks. If you're so hot on OO - go and check out
> Smalltalk instead of C++ - that'll give you some idea about
> proper design.
it was not my intention to attack you personally (and i excuse myself for it
if that is how it came across), just to alert you.
best regards,
-- j
Jorn W Janneck
> Jorn W Janneck wrote:
>
> <snip>
>
> > >
> > > To name a few.
> >
> > sure, but you know what he meant, so.
>
> No, I did not 'know' what 'gbp' meant. I've watched 'gbp' make a number
> of vague and/or inaccurate technical statements in the other c.l.j.*
> groups. I felt it was necessary to question the statement about
> interfaces not holding fields.
oh, then i misunderstood your comment. my mistake.
> > > > They connot be concrete.
> > >
> > > Nor would it make sense for them to be concrete, since their primary
> > > purpose is abstraction.
> >
> > the primary purpose of classes is abstraction, i do not see how the
> > inability to instantiate interfaces (and of course you are right, it
doesn't
> > make sense to instantiate them, as there is nothing to instantiate) is
> > related to their purpose to facilitate abstraction.
>
> The opposite of concrete is abstract. That is the point I was making.
i understood that, but i think in the technical use of the term 'abstract'
here, playing on the common definition of these terms is misleading. a class
(even a non-abstract, i.e. concrete one) is an implementation of an
'abstract data type', and i think the purpose of interfaces and classes is
in fact abstraction in this sense.
the fact that interfaces are abstract (in the 'abstract class' sense) is,
imo, a consequence of the fact that any other choice would basically open
the can of worms that come with implementing mi, and not the purpose of an
interface.
let me ask you this: assume the designers of java would have included mi
into the language, say as in eiffel. do you think they wold have included
interfaces as well?
> Saying that an interface is a second rate class because it cannot be
> concrete is a flawed statement. You may as well call abstract (fully or
> otherwise) classes 'second class' for the same reason. I consider
> classes to be an abstraction of reality, whereas interfaces are an
> abstraction of classes. Abstract classes lie somewhere in between.
i think the point is that abstract classes (with mi) essentially form a
continuum that completely subsumes interfaces. i think this is what gbp
meant with
"When I said interfaces were
second rate classes I meant that interfaces are not as good as
multiple inheritance."
i think that is a plausible proposition.
> > > Interfaces aren't second rate classes, they are
> > > a parallel concept.
> >
> > i don't really think so. interfaces are equivalent to fully abstract
> > classes, with the added resriction that they may only extend other
> > interfaces. they are by no means orthogonal to classes,
>
> And the added benefit that a single class may implement many of them.
which, in mi, you of course have as well.
> Note I said 'parallel', not orthogonal.
but again, in programming language design, 'parallel' is not the opposite of
'orthogonal'. 'redundant' is. and it is mostly (except on the syntactical
and type checking side) considered a bad thing.
> In Java, the interface provides
> some flexibility that doesn't exist with classes, even fully abstract
> ones.
right, but that seems besides the point of gbp, and certainly besides mine.
if you *assume* single inheritance of implementation (and static typing),
which you need to make the above statement true, you are absolutely right,
you need interfaces to fix the shortcomings wrt the type hierarchy.
> You may argue that this is a 'limitation' when compared to other
> languages, but such comparisons aren't very useful. If the original
> poster was calling interfaces second rate classes in the context of
> discussing the concept of classes as a whole (i.e. not within the
> context of Java), then the argument may hold more water. It is not
> clear that this is what was meant.
i think gbp explained it: "When I said interfaces were
second rate classes I meant that interfaces are not as good as
multiple inheritance."
it seems fairly clear to me.
> > not even from a
> > language point of view: reflection treats them as classes, they are
stored
> > the way classes are, and i think any semantic theory would treat them as
> > (fully abstract) classes.
>
> Or perhaps the language, the VM and Reflection deal with Types. Note
> that the JLS and the JVMS tend to avoid lumping the two concepts (class
> and interface) together. At times I wish they had used the term 'Type'
> more often, as it would eliminate some areas of confusion.
perhaps. but assuming that the people at sun do not call things random names
(i.e. they connect with a name a certain intention), i think it is revealing
to have interfaces being instances of class Class.
but if you will, i assume gbp would agree to the statement that interfaces
are second-rate types (i certainly would).
> > the fact that they may contain fields only underpins this.
> >
> > > The highest entity in Java is the 'Type'. Classes
> > > and Interfaces are both 'Types'.
> >
> > sure. but that is just juggling words. except for a few restrictions on
> > inheritance (which are basically driven by implementation concerns and
maybe
> > by a wish to simplify the language), interfaces appear as abstract
classes.
>
> Except for the multiple implementation bit. Perhaps fully abstract
> classes are merely interfaces with the added restriction that several
> cannot be subclassed by a single class. It all depends on the end from
> which you approach it.
and i think that gbp made it abundantly clear that the restrictions of
single-inheritance were not assumed in the original statement.
> > i think the original poster felt that anything you could do with
interfaces
> > you could do with multiple inheritance of fully abstract classes. i
think he
> > is right.
>
> I doubt anyone would disagree. However, I don't pretend to know what the
> original poster 'felt' about anything. I can only read what was written
> and comment on that. To call Interfaces 'second rate classes' hardly
> seems equivalent to the statement 'anything you can do with interfaces
> can be done with multiple inheritance of fully abstract classes'. Not
> to me anyway.
so what about the explanation that i quoted twice? even tough it contains
the phrase 'not as good as', i think it's pretty clear what that means here.
you may disagree, and that's very fine with me.
> > > "Multiple inheritance--and all the problems it generates--was
discarded
> > > from Java. The desirable features of multiple inheritance are provided
> > > by interfaces--conceptually similar to Objective C protocols."
> >
> > that is 'desirable' in the eyes of the java designers. if all you got is
a
> > hammer...
>
> Well, when you create your own language, feel free to do with it as you
> see fit. I cannot fault Sun for doing more than I am capable of doing
> myself.
i think i disagree with that. i can fault a car manufacturer for building
cars below the current state of the art (within reasonable limits of
technical viability, of course), even though i could not build a car myself.
> Were some corners cut? Probably. Were some bad decisions
> made? Certainly. But is the end result all that terrible? I don't
> think so. I prefer to use the tools in the way they were intended to be
> used. If the tool isn't meant to tighten bolts, no sense in complaining,
> since there are other tools that are capable of doing the job. However,
> since I unwrapped my Java toolbox, I haven't had much need to use the
> others out there. Except for a smattering of JNI with the Win32 API,
> which I find somewhat painful.
does that mean that general happiness with something disqualifies from
critiquing it? wouldn't that imply that things can never be improved, except
by people who loathe them?
i also prefer java for many tasks (that's why i read this newsgroup), but
that does not mean that i think it is a good language design for its time,
or even agree with all its design decisions.
regards,
-- j
Thomas Maslen
[...]
> You have to apply OO judiciously, not blindly. There are some
> instances where a full-blown interface is unnecessarily restrictive.
> Sorting is a good example -- all a sorting algorithm needs is a
> function that can compare two objects and return whether one is
> greater, less than or equal to the other. This is exactly what the
> standard C library qsort() does. You gain nothing by being forced
> to subclass a specific interface
@see java.text.Collator -- if you don't have a javadoc window open, that's
http://java.sun.com/products/jdk/1.2/docs/api/java/text/Collator.html
Note that it implements java.util.Comparator, i.e. it is exactly the sort
(no pun intended) of sorting callback that you pass to, say, Arrays.sort()
or new TreeMap(Comparator).
Note also that it contains a considerable amount of instance data -- so if
you had just used a pure function instead then either you would have had to
pass the state in another argument, like the horrible old C thing of passing
both a function pointer and a void * for the required data, or you would have
had to do something gross like using global data (too bad if you wanted to
simultaneously use a Collator for Murcan and a Collator for real English).
This doesn't apply just to methods for sorting; many callbacks need instance
data, and having an honest-to-god object rather than a plain function gives
me a type-safe way to bring that data along with the function.
> and give your comparison method a specific name just to get the same
> functionality in an OO language.
SortedSet fred = new TreeSet(new Comparator()
{
public int compare(Object o1, Object o2) {
return munge(o1).compareTo(munge(o2));
}
/**
* Strip trailing ".suffix" before doing comparison.
* Pretty bogus, but will do for this example.
*/
private static String munge(Object o) {
String original = (String) o;
int pos = original.lastIndexOf('.');
return (pos >= 0) ? original.substring(0, pos) : original;
}
});
Look Ma, no "specific name"...
(Well, under the covers the compiler generates a funny name, but I don't
have to worry my little head with it).
Thomas Maslen
mas...@pobox.com
David Glass
was referring to the fact that you have to implement a specific method
as named in the interface, not that you have to create a name for the
class implementing the interface. In your example, you couldn't just use
any method with the same signature and return type as compare(), you
still had to use the specific name compare().
Jim Sculley
>
> i understood that, but i think in the technical use of the term 'abstract'
> here, playing on the common definition of these terms is misleading. a class
> (even a non-abstract, i.e. concrete one) is an implementation of an
> 'abstract data type', and i think the purpose of interfaces and classes is
> in fact abstraction in this sense.
>
I tend to look at it from inside the bounds of the langauge, where
classes are more or less 'concrete' things (unless declared abstract).
So this seems to be a difference in viewpoint more than anything.
> the fact that interfaces are abstract (in the 'abstract class' sense) is,
> imo, a consequence of the fact that any other choice would basically open
> the can of worms that come with implementing mi, and not the purpose of an
> interface.
>
> let me ask you this: assume the designers of java would have included mi
> into the language, say as in eiffel. do you think they wold have included
> interfaces as well?
I think it is possible that they would have kept interfaces. I think
that the concept of a 'fully abstract' class is different enough from a
regular class or a partially abstract class to warrant a separate type.
But that's just me.
>
> > Saying that an interface is a second rate class because it cannot be
> > concrete is a flawed statement. You may as well call abstract (fully or
> > otherwise) classes 'second class' for the same reason. I consider
> > classes to be an abstraction of reality, whereas interfaces are an
> > abstraction of classes. Abstract classes lie somewhere in between.
>
> i think the point is that abstract classes (with mi) essentially form a
> continuum that completely subsumes interfaces. i think this is what gbp
> meant with
>
> "When I said interfaces were
> second rate classes I meant that interfaces are not as good as
> multiple inheritance."
Perhaps, but the term 'second-rate' to me implies an inferiority in
interfaces. Being a subset does not implicitly make them inferior in my
opinion. Especially when you consider your self-described 'can of
worms' that can be associated with MI. Given the choice between no MI,
partial MI, and full MI, I might still choose the partial MI provided by
interfaces.
<snip>
>
> but again, in programming language design, 'parallel' is not the opposite of
> 'orthogonal'. 'redundant' is. and it is mostly (except on the syntactical
> and type checking side) considered a bad thing.
Perhaps, but I'm not a programming language designer. Orthogonal *is*
the opposite of parallel in my mind. A simple difference in mental
vocabulary.
>
> > In Java, the interface provides
> > some flexibility that doesn't exist with classes, even fully abstract
> > ones.
>
> right, but that seems besides the point of gbp, and certainly besides mine.
> if you *assume* single inheritance of implementation (and static typing),
> which you need to make the above statement true, you are absolutely right,
> you need interfaces to fix the shortcomings wrt the type hierarchy.
The beginning of my statement 'In Java' implies that I have made that
assumption. I was speaking within the context of the language.
>
> > You may argue that this is a 'limitation' when compared to other
> > languages, but such comparisons aren't very useful. If the original
> > poster was calling interfaces second rate classes in the context of
> > discussing the concept of classes as a whole (i.e. not within the
> > context of Java), then the argument may hold more water. It is not
> > clear that this is what was meant.
>
> i think gbp explained it: "When I said interfaces were
> second rate classes I meant that interfaces are not as good as
> multiple inheritance."
>
> it seems fairly clear to me.
To me, that is about as clear as 'Beer is not as good as whiskey'.
<snip>
> >
> > Or perhaps the language, the VM and Reflection deal with Types. Note
> > that the JLS and the JVMS tend to avoid lumping the two concepts (class
> > and interface) together. At times I wish they had used the term 'Type'
> > more often, as it would eliminate some areas of confusion.
>
> perhaps. but assuming that the people at sun do not call things random names
> (i.e. they connect with a name a certain intention), i think it is revealing
> to have interfaces being instances of class Class.
That all depends on when they came about. If they were 'thought up'
late in the game, it may have been problematic to change the compiler
and VM to deal with this new entity. The VM itself is somewhat cagey
with respect to interfaces. For instance, the 'super_class' item in the
class file has this description:
"For an interface, the value of the super_class item must always be a
valid index into the constant_pool table. The constant_pool entry at
that index must be a CONSTANT_Class_info structure representing the
class Object."
This is decidedly different from the entry for a regular class. I don't
know when the concept of the interface was integrated into Java, so I
can't assume that Sun intended for them to be considered classes all
along. If the two concepts were there from the start, I would have
expected 'type' to take the place of 'class' in some of the syntax (i.e.
getType() as opposed to getClass()).
>
> but if you will, i assume gbp would agree to the statement that interfaces
> are second-rate types (i certainly would).
>
And I would disagree. But as always, everyone is entitled to their own
opinion.
<snip>
> > I doubt anyone would disagree. However, I don't pretend to know what the
> > original poster 'felt' about anything. I can only read what was written
> > and comment on that. To call Interfaces 'second rate classes' hardly
> > seems equivalent to the statement 'anything you can do with interfaces
> > can be done with multiple inheritance of fully abstract classes'. Not
> > to me anyway.
>
> so what about the explanation that i quoted twice? even tough it contains
> the phrase 'not as good as', i think it's pretty clear what that means here.
> you may disagree, and that's very fine with me.
Again, I don't consider 'not as good as' to be clear in any sense.
> >
> > Well, when you create your own language, feel free to do with it as you
> > see fit. I cannot fault Sun for doing more than I am capable of doing
> > myself.
>
> i think i disagree with that. i can fault a car manufacturer for building
> cars below the current state of the art (within reasonable limits of
> technical viability, of course), even though i could not build a car myself.
Many people don't want 'state of the art' cars (or languages). Any auto
show is full of cars with interesting designs and features, but if they
showed up at the dealership tomorrow, sales would probably not be
brisk. It is similar with languages. Big changes can be difficult for
some people to accept. I believe I could switch from Java to Eiffel or
Smalltalk with little difficulty, but not everyone may feel this way.
>
> does that mean that general happiness with something disqualifies from
> critiquing it?
Certainly not. Critique away. You have proven many times in the past
to be quite knowledgeable. I have not seen the same past performance
from 'gbp', which is why I entered the discussion in the first place.
> wouldn't that imply that things can never be improved, except
> by people who loathe them?
I don't think that is implied at all.
>
> i also prefer java for many tasks (that's why i read this newsgroup), but
> that does not mean that i think it is a good language design for its time,
> or even agree with all its design decisions.
Nor is the modern internal combustion engine a good solution for its
time, but still it proves very useful. Mainly because it is simple,
familiar and widely accepted, much like Java. Eiffel, Smalltalk, et. al.
are analagous to fuel cells. Their time may indeed come, pushing the
'second rate' languages into history books. I will however, refrain
from holding my breath.
Jim S.
oxbow_lakes
<pre>
>i still do not understand why the use of abstract classes does
>this (force implementation details on me) -- the point about mi
>with abstract classes vs interfaces is that in abstract classes
>the implementer can choose precisely how much implementation he
>or she would like to make inheritable.
It forces implementation details in that you are forced to
subclass a particular class, which with interfaces in Java you
aren't. Obviously with MI this is no restriction. It seems that
we are just arriving at Java from diff points - you from an MI
pov and me from an SI (Smalltalk) pov. Maybe there isn't much to
choose between the 2.
<p><pre>
>it was not my intention to attack you personally (and i excuse
>myself for it if that is how it came across), just to alert you.
Fair enough - reading the "tone" of my original - I did come
across a bit strong (point taken :-). Having said that, the
original poster was "dissing" interfaces without apparently
having thought about the power they introduce into the language.
You say "why introduce an extra concept into a language?" - that
depends where you are coming from, I mean if Java had have been
MI, that would have been an "extra concept" for me. Maybe they
chose interfaces as they are a fundamental design pattern (event
though they don't give any extra functionality over MI)
</html>
John Lockwood
Oh, I'm a Windows user, and I not only know that, I know how to spell
Windows.
John
none
thats true... Windows has made computers so easy to use that
non-eggheads can actually use them