JDK: Which patterns?
Karsten Wutzke
Right now I'm pretty much into 'design patterns' and thus I'd like to
know which patterns are available or have been implemented by the JDK. I
know of:
Adapter (implemented)
Observer (available)
What about?:
Composite (probably interface Composite)
Algorithm (probably Algorithm* classes)
Factory Method
Abstract Factory
Decorator (implemented for the whole GUI/Swing slew?)
Builer
Mediator
Memento
.
.
.
Maybe someone knows... it's rather a 'fun' question...
Karsten
tew...@my-deja.com
with patterns and Swing. In the process of discussing Swing
implementations, it dicusses patterns which Swing uses.
Sent via Deja.com http://www.deja.com/
Before you buy.
elidan1
<karsten...@starconcept.com> wrote:
>Hi all!
>
>Right now I'm pretty much into 'design patterns' and thus I'd
like to
>know which patterns are available or have been implemented by
the JDK. I
>know of:
>
>Adapter (implemented)
>Observer (available)
>
>What about?:
>Composite (probably interface Composite)
>Algorithm (probably Algorithm* classes)
>Factory Method
>Abstract Factory
>Decorator (implemented for the whole GUI/Swing slew?)
>Builer
>Mediator
>Memento
>..
>..
>
>Maybe someone knows... it's rather a 'fun' question...
>
>Karsten
>
>
>
>
Wesley,2000. Just got it myself, so I'll reserve an opinion until
I'm done reading it.
elidan1
for mail null IS null
nulle...@nullzahav.net.il
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
Steve Chapel
news:392D8BA0...@starconcept.com...
> Hi all!
>
> Right now I'm pretty much into 'design patterns' and thus I'd like to
Most patterns have to be crafted into your own code; you can't just use
patterns from a library. Some patterns, such as Observer, can be implemented
in a library, but most cannot. For example, there are Adapter classes for
event listeners in the Java API, but those adapters won't help you write
your own adapters.
--
Java Programmers FAQ: http://www.afu.com/javafaq.html
Java Docs: http://java.sun.com/docs/
Dale King
Not familiar enough with the rest of the patterns.
Karsten Wutzke wrote:
>
> Hi all!
>
> Right now I'm pretty much into 'design patterns' and thus I'd like to
> know which patterns are available or have been implemented by the JDK. I
> know of:
>
> Adapter (implemented)
> Observer (available)
>
> What about?:
> Composite (probably interface Composite)
> Algorithm (probably Algorithm* classes)
> Factory Method
> Abstract Factory
> Decorator (implemented for the whole GUI/Swing slew?)
> Builer
> Mediator
> Memento
> .
> .
> .
>
> Maybe someone knows... it's rather a 'fun' question...
>
> Karsten
--
--- Dale King
Recruiters: I am not willing to relocate outside of Indianapolis!
Laurence V
>"Karsten Wutzke" <karsten...@starconcept.com> wrote in message
>news:392D8BA0...@starconcept.com...
>> Hi all!
>>
>> Right now I'm pretty much into 'design patterns' and thus I'd like to
>> know which patterns are available or have been implemented by the JDK...
>
>
>Most patterns have to be crafted into your own code; you can't just use
>patterns from a library. Some patterns, such as Observer, can be implemented
>in a library, but most cannot.
Another design pattern which can be promoted to library status is Visitor. I've used this pattern for a number of years
in the shape of the following interfaces:
DirectoryVisitor: visit every file and/or directory in some starting directory, optionally recursively.
TextFileVisitor: visit every line of text in a text file.
WebVisitor: visit every hyperlink of a starting web page.
ZipFileVisitor: visit every entry of a ZIP (or JAR) file.
... Other classes provide the necessary "visiting engines" for these interfaces. Saves a heck of a lot of time when
you're able to reuse these things (and in my experience, the investment put into writing the interfaces and support
classes has definitely paid off).
L.
Laurence V
>Hi all!
>
>Right now I'm pretty much into 'design patterns' and thus I'd like to
>know which patterns are available or have been implemented by the JDK. I
>know of:
>
>What about?:
>Composite (probably interface Composite)
That's clearly used by AWT/Swing with Container being able to contain more Containers, ad infinitum.
>Factory Method
Plenty of those around. Border in Swing, also the URL content handler framework in java.io, IIRC.
L.
GeoWCherry
available in java.util.Observable (Model) and java.util.Observer (View).
George W. Cherry
http://sdml.com
Jon Skeet
> The java.io classes use the Decorator pattern.
Surely that's Component.repaint() isn't it? ;)
--
Jon Skeet - sk...@pobox.com
http://www.pobox.com/~skeet/
Laurence V
>You probably already know this, but the Model-View pattern is very well
>available in java.util.Observable (Model) and java.util.Observer (View).
Well, I'd quote Swing as a prime example of an *entire* library which relies heavily on the MVC pattern.
Anyway, I don't know many people who use Observable/Observer. Of course, that's probably because Sun botched the
inclusion of this "pattern" in the Core API: Observable should have been an interface, not a class! Look around you (in
the Core API) and you'll find that the bulk of the really powerful, flexible and clever designs in the API are built on
top of interfaces, not classes.
L.
Dale King
they are quite critical of the Observer/Observable combination. The main
criticisms are that:
- Inheriting from Observer doesn't pass their inheritance test.
Inheriting from Observer is a bad design. They claim Observer is nothing
but utility methods and objects that inherit from it are not truly a
type of Observable.
- Observer is tied to Observable since it requires an Observable
parameter. The type of that parameter should just be an Object or maybe
an interface.
Unfortunately, I haven't finished that chapter to see what their
recommendations are.
It is a pretty good book by the way. It cleared a few things up for me
regarding composition vs. inheritance and some of the classic multiple
inheritance arguments.
GeoWCherry wrote:
>
> You probably already know this, but the Model-View pattern is very well
> available in java.util.Observable (Model) and java.util.Observer (View).
>
> George W. Cherry
> http://sdml.com
--
Mark Wilden
>
> Actually, I am reading Java Design, 2nd Edition by Coad and Mayfield and
> they are quite critical of the Observer/Observable combination. The main
> criticisms are that:
>
>
> It is a pretty good book by the way. It cleared a few things up for me
> regarding composition vs. inheritance and some of the classic multiple
> inheritance arguments.
I was less impressed. After getting through it, you realise that they
want everything to have an interface. This flies right against XP, if
that's any concern.
Paul Hill
Jon Skeet wrote:
>
> Ki...@TCE.com wrote:
> > The java.io classes use the Decorator pattern.
>
> Surely that's Component.repaint() isn't it? ;)
Having such method is the minimum requirement for such a pattern
(as is typical of a pattern it the method could be called something different.
It is not exact names that make it a pattern but the way certain objects
work together.
A Decorator is something that gets added to something else to
extend it.
[DP p 175]
<quote>
Intent:
Attach additional responsibilites to an object dynamically. Decorators
provide a flexible alternative to subclassing for extending functionality.
</quote>
Each component inside a jFrame etc. is a decorator of the Frame.
I would have called this pattern Decoration, but I wasn't the author.
-Paul
--
Myriad Genetics: http://www.myriad.com/
Java FAQ: http://www.afu.com/javafaq.html (Section 9, Computer Dating)
Dale King
Components added to a Frame are definitely not the Decorator pattern.
The Decorator pattern is also known as the Wrapper pattern, which is
probably more descriptive of what it does.
A classic example in Java is the FilterInputStream class (and its many
subclasses BufferedInputStream, DataInputStream, CheckedInputStream,
InflaterInputStream, DigestInputStream, LineNumberInputStream,
PushbackInputStream) which is a Decorator of an InputStream. It provides
the same API as the InputStream which it wraps, but allows you to add
additional capability. It is this idea of adding functionality by
wrapping another object while implementing the same API that is
characteristic of the Decorator pattern.
I too, think Decorator is an extremely poor name.
Paul Hill wrote:
>
> A Decorator is something that gets added to something else to
> extend it.
>
> Attach additional responsibilites to an object dynamically. Decorators
> provide a flexible alternative to subclassing for extending functionality.
>
> Each component inside a jFrame etc. is a decorator of the Frame.
>
> I would have called this pattern Decoration, but I wasn't the author.
--
Paul Hill
Dale King wrote:
>
> I think you have a flawed understanding of the Decorator pattern.
> Components added to a Frame are definitely not the Decorator pattern.
Ooops,
You are right. The Decorator contains the 'decorated' inside it, adding
extra behavior in addition to the object, so each component would not
be a Decorator of a Frame.
Cheers,
Laurence V
Surely almost any technique flies against some other technique? I don't think that "flying against XP" is a valid
argument to criticize something like recommending a heavy reliance on interfaces... and in any case, as far as I
understand what XP is all about, I dont see how using lots of interfaces goes against XP. Can you elaborate?
L.
jjprime
delightful little book. Its subtitle is "Design Styles and
Idioms for Effective Java". An early claim in the book is that
a 'package' is an example of the Facade.
gmou...@my-deja.com
Mark Wilden <ma...@mwilden.com> wrote:
> I was less impressed. After getting through it, you realise that they
> want everything to have an interface. This flies right against XP, if
> that's any concern.
>
While I am fairly new to XP, I don't recall anything in Beck's book even
mentioning interfaces. Are you trying to say that using interfaces tend to
resolve more than the present problem, ie not programming for today?
Interesting idea.
Mark Wilden
>
> Surely almost any technique flies against some other technique?
I don't know about that, but I suppose it's possible.
>I don't think that "flying against XP" is a valid
> argument to criticize something like recommending a heavy reliance on interfaces.
It depends on whether you agree with XP, doesn't it?
>.. and in any case, as far as I
> understand what XP is all about, I dont see how using lots of interfaces goes against XP. Can you elaborate?
Sure. XP is against building in flexibility to meet future requirements.
The reason is that this adds work that may never be necessary. What they
would say is that if you need interfaces to make a piece of code work
better, then use them. But don't use them simply because you think you
might need them one day.
XP believes that change is easier than is commonly thought. So they
don't worry about trying to predict the future, since that's not
possible anyway. They reject flexibility for its own sake, in favour of
getting the current needds met quickly.
Mark Wilden
>
> While I am fairly new to XP, I don't recall anything in Beck's book even
> mentioning interfaces. Are you trying to say that using interfaces tend to
> resolve more than the present problem, ie not programming for today?
Yes, exactly. When Coad builds a class with a getName() method, he
thinks that class should extend the IHasName interface, just in case he
ever ends up with two classes that he wants to treat the same WRT names.
(This is a bit of an exaggeration, but I've already packed my copy of
his book.)
XP would say that it's quite easy to add the interface later, when and
if it's ever needed.
Michael Schuerig
> gmou...@my-deja.com wrote:
> >
> > While I am fairly new to XP, I don't recall anything in Beck's book even
> > mentioning interfaces. Are you trying to say that using interfaces tend to
> > resolve more than the present problem, ie not programming for today?
>
> Yes, exactly. When Coad builds a class with a getName() method, he
> thinks that class should extend the IHasName interface, just in case he
> ever ends up with two classes that he wants to treat the same WRT names.
Sounds like a reasonable idea.
Keep in mind that life is different in Smalltalk. There, if you add the
appropriate methods to classes they implicitly conform to the same
protocol. It's not that easy in Java and most other
somewhat-statically-typed OOPLs. In these languages you have to
explicitly indicate which protocols a class conforms with.
> XP would say that it's quite easy to add the interface later, when and
> if it's ever needed.
This depends very much on your environment. It's probably true in the
common Smalltalk IDEs, both because of the language and the facilities
of the IDEs. But it's hardly as easy when you're writing Java in vanilla
XEmacs + JDE, say.
Michael
--
Michael Schuerig
mailto:schu...@acm.org
http://www.schuerig.de/michael/
Laurence V
>>.. and in any case, as far as I
>> understand what XP is all about, I dont see how using lots of interfaces goes against XP. Can you elaborate?
>
>Sure. XP is against building in flexibility to meet future requirements.
>The reason is that this adds work that may never be necessary. What they
>would say is that if you need interfaces to make a piece of code work
>better, then use them. But don't use them simply because you think you
>might need them one day.
>
>XP believes that change is easier than is commonly thought. So they
>don't worry about trying to predict the future, since that's not
>possible anyway. They reject flexibility for its own sake, in favour of
>getting the current needds met quickly.
hmm.. I think there's loads of scope for interpretation wars here.
If the central XP philosophy is really to recognize that change is far more rapid and disruptive as normally assumed,
then I, as a hypothetical XP programmer, would personally tend to want to build on the most flexible foundation
possible. But RAD-style development (XP is a form of RAD, no?) doesn't have the time to create flexible foundations,
IMO.
The way I interpret your statements is that XP style development seems to be prepared to have its code sand castles
knocked down flat by change every time change decides to disrupt things. Personally, I belong in the camp of people who
believe that change needs to be addressed by building systems/architectures/libraries which can RESIST and ABSORB the
hits that change inflict on your developing product. .. obviously, people like me are in serious trouble when the
magnitude of the change is *so* great that the code can't absorb the impact gracefully. In such cases I admit XP *may*
be a superior approach.
BTW, my development philosophy is very heavily based on code reuse. How does XP deal with the reuse issue? The way I
interpret what you wrote, I can't see much scope for a reuse philosophy within XP.. is that correct?
L.
Laurence V
>gmou...@my-deja.com wrote:
>>
>> While I am fairly new to XP, I don't recall anything in Beck's book even
>> mentioning interfaces. Are you trying to say that using interfaces tend to
>> resolve more than the present problem, ie not programming for today?
>
>Yes, exactly. When Coad builds a class with a getName() method, he
>thinks that class should extend the IHasName interface, just in case he
>ever ends up with two classes that he wants to treat the same WRT names.
>(This is a bit of an exaggeration, but I've already packed my copy of
>his book.)
>
>XP would say that it's quite easy to add the interface later, when and
>if it's ever needed.
Well, XPers would be wrong in claiming this. If you remember when the Collection framework came out, Sun made a big
point of using the framework by declaring your Collection variables using the *interface* types, not the implementation
types. E.g.
List carsSoldThisMonth = new Vector();
instead of
Vector carsSoldThisMonth = new Vector();
This interface type-centric approach allows the interchangability of actual implementations.
If your code doesn't use interfaces, then by definition you can't be declaring your variables using interface types. If
you subsequently decide that you need an interface after all, then you need to make very invasive and tricky changes to
your code base. If that's what XP thinks is acceptable, then my openness towards the XP approach starts to fade at this
point.
L.
GeoWCherry
XP believes that change is easier than is commonly thought. So they
don't worry about trying to predict the future, since that's not
possible anyway. They reject flexibility for its own sake, in favour of
getting the current needds met quickly.
I would add "and clearly": "getting the current needs met quickly and clearly".
Interfaces are elegant design specifications, but that's no reason to think
every class method should be the implementation of some interface. That would
obfuscate the code with interfaces.
George.
Mark Wilden
>
Sun's approach required more flexibility than most developers need to
provide in their own code. If you're writing a class to be used by
hundreds of thousands of people, you need to try to predict how it's
going to be used more than if you're writing code for one organisation.
> If your code doesn't use interfaces, then by definition you can't be declaring your variables using interface types. If
> you subsequently decide that you need an interface after all, then you need to make very invasive and tricky changes to
> your code base. If that's what XP thinks is acceptable, then my openness towards the XP approach starts to fade at this
> point.
Does that mean that every class you write implements an interface?
Mark Wilden
>
> If the central XP philosophy is really to recognize that change is far more rapid and disruptive as normally assumed,
Half right. They feel that change is inevitable, impossible to predict,
and easier to accomodate than it used to be (once you know what really
needs to be done).
> then I, as a hypothetical XP programmer, would personally tend to want to build on the most flexible foundation
XP says that most of that flexibility will never be used, hence it would
be a waste of time.
> The way I interpret your statements is that XP style development seems to be prepared to have its code sand castles
> knocked down flat by change every time change decides to disrupt things.
No, they're saying that change is not that hard to accomodate. What _is_
hard is predicting what will change ahead of time.
> Personally, I belong in the camp of people who
> believe that change needs to be addressed by building systems/architectures/libraries which can RESIST and ABSORB the
> hits that change inflict on your developing product.
If you can identify where those changes will come from ahead of time,
fine. If you can't...
> BTW, my development philosophy is very heavily based on code reuse. How does XP deal with the reuse issue? The way I
> interpret what you wrote, I can't see much scope for a reuse philosophy within XP.. is that correct?
I don't think XP really addresses code reuse, that I can remember. It's
such an obviously desirable attribute of any system, that it's not
necessary to point out.
But again, there is designing code to be reused (by giving it a firm and
clean interface) and designing it to be reused in ways that could have
never been imagined. The latter is a chimerical goal.
Mark Wilden
>
> Mark Wilden <ma...@mwilden.com> wrote:
>
> > Yes, exactly. When Coad builds a class with a getName() method, he
> > thinks that class should extend the IHasName interface, just in case he
> > ever ends up with two classes that he wants to treat the same WRT names.
>
Well, I think it's plain dumb. :) If you _need_ an interface, then add
one. If you don't need an interface, keep things simple.
> Keep in mind that life is different in Smalltalk. There, if you add the
> appropriate methods to classes they implicitly conform to the same
> protocol. It's not that easy in Java and most other
> somewhat-statically-typed OOPLs. In these languages you have to
> explicitly indicate which protocols a class conforms with.
Right, I understand.
> This depends very much on your environment. It's probably true in the
> common Smalltalk IDEs, both because of the language and the facilities
> of the IDEs. But it's hardly as easy when you're writing Java in vanilla
> XEmacs + JDE, say.
Could you be more specific? I don't think it's that hard to slap an
interface onto a class.
Michael Schuerig
> Michael Schuerig wrote:
[Adding an interface "above" an existing and widely used class.]
> > This depends very much on your environment. It's probably true in the
> > common Smalltalk IDEs, both because of the language and the facilities
> > of the IDEs. But it's hardly as easy when you're writing Java in vanilla
> > XEmacs + JDE, say.
>
> Could you be more specific? I don't think it's that hard to slap an
> interface onto a class.
The easy part is to declare the interface and having the existing class
implement it. The tedious part is to change all the uses of the class to
uses of the interface, where appropriate.
Michael Schuerig
> Half right. They feel that ...
> XP says that ...
> No, they're saying that ...
What do "they" do, if you follow their advice an fail nevertheless?
Don't be overly enthusiastic. Try XP and _then_ judge the claims based
on your experiences.
Mark Wilden
>
> The easy part is to declare the interface and having the existing class
> implement it. The tedious part is to change all the uses of the class to
> uses of the interface, where appropriate.
Sounds like a search and replace operation to me...
See Martin Fowler's "Refactoring" for strategies for changing code.
Michael Schuerig
> Michael Schuerig wrote:
> >
> > The easy part is to declare the interface and having the existing class
> > implement it. The tedious part is to change all the uses of the class to
> > uses of the interface, where appropriate.
>
> Sounds like a search and replace operation to me...
Nope.
Original situation:
Definitions:
class X {
...
}
Sample use:
void f() {
X x = new X();
...
}
New, desired situation:
Definitions:
interface X {
...
}
class XImpl implements X {
...
}
Sample use:
void f() {
X x = new XImpl();
}
I'd be surprised if a simple search and replace was all that is needed
for the transform. The effort might be tiny for each occurrence, but it
looks like it's linear not constant.
> See Martin Fowler's "Refactoring" for strategies for changing code.
Read it when it appeared. Got to grab it back from a cow-orker.
Mark Wilden
>
> Original situation:
>
> Definitions:
>
> class X {
> ...
> }
>
> Sample use:
>
> void f() {
> X x = new X();
> ...
> }
>
>
> New, desired situation:
>
> Definitions:
>
> interface X {
> ...
> }
>
> class XImpl implements X {
> ...
> }
>
> Sample use:
>
> void f() {
> X x = new XImpl();
> }
But you wouldn't use X as the name for the interface, but for the
implementation. However, I admit that it would take more than a
search-and-replace. The change would, however, be mechanical.
Fowler mentions that Smalltalk has good tools for this kind of
refactoring. Seems to me that Java is lacking. It wouldn't be rocket
science to create a tool that would make this kind of change.
My point, however, is that if you need interfaces up front, then of
course you should create them. The other position is that you should
create an interface for _every_ class, since you may need it one day.
That's the kind of crystal-ball gazing that XP is against.
Laurence V
>Does that mean that every class you write implements an interface?
Not at all, but I consider a "healthy" ratio of interfaces to classes in a project as an indicator of quality (I stress:
an *indicator*.. not *proof*). Unlike people like Capers Jones and the like, I do not have lots of third-party data to
back up my fondness of interfaces. My personal experience has shown that the correct use of interfaces very often leads
to very elegant solutions that can be reused time and time again. So, although I don't use interfaces when they're not
required (I do not agree with the Coad lets-make-everything-an-interface approach), I do always ask myself the question
"Would an interface make sense here? Would the use of an interface sow the seed for later reuse in this and similar
cases?"
L.
Michael Schuerig
> Michael Schuerig wrote:
[snippage]
> But you wouldn't use X as the name for the interface, but for the
> implementation.
Of course, I would! "X" is the name of an interesting abstraction in my
problem domain. At first I thought there was just one sensible or useful
implementation, thus I directly define X as a class. Later I realize
that there are several more implementations I need. The original
abstraction remains and therefore ought to keep its name. But I can't
associate one specific implementation with the abstraction, thus I have
to move the original implementation to a new class and define additional
classes for the other implementations.
> Fowler mentions that Smalltalk has good tools for this kind of
> refactoring. Seems to me that Java is lacking. It wouldn't be rocket
> science to create a tool that would make this kind of change.
I'm not holding my breath although I hope to see this kind of tools as
soon as possible. From what I know about Smalltalk, it's usually
possible to access the life parsing data and work on the image. In
common Java environments (apart from VAJ) you'd have to parse everything
yourself.
> My point, however, is that if you need interfaces up front, then of
> course you should create them. The other position is that you should
> create an interface for _every_ class, since you may need it one day.
> That's the kind of crystal-ball gazing that XP is against.
I know of no-one who creates an interface for each class up front. And
AFAIR (don't have my copy handy) Coad ("Java Design") doesn't advocate
this.
I regularly work in a way that I start out with a concrete class, even
if I know that it will get an interface on top of it later on. When I
write a second class implementing the same implied interface I extract
the interface. Somewhere around this time I consider pulling up common
functionality into an abstract superclass. I fully accept to rewrite
code, but the important thing is that up to this stage none of the
involved classes are used widely. Changes are pretty much local to a
package. Sometimes I'm even smart enough to successfully do
MediumDesignUpFront and get interfaces and classes right on the drawing
board.
Mark Wilden
> > implementation.
>
> Of course, I would! "X" is the name of an interesting abstraction in my
> problem domain.
Take the example I gave before (or any of Coad's examples): a Customer
has a name, therefore conforms to the IHasName interface (Coad also
believes in the I prefix, which I can buy). There may be many other
interfaces it conforms to, as well. So in the general case, the
interface won't have the same name as the class.
> At first I thought there was just one sensible or useful
> implementation, thus I directly define X as a class. Later I realize
> that there are several more implementations I need. The original
> abstraction remains and therefore ought to keep its name. But I can't
> associate one specific implementation with the abstraction, thus I have
> to move the original implementation to a new class and define additional
> classes for the other implementations.
That describes pretty well how I (and XP) would do it. The key phrase is
'later I realise'.
> I'm not holding my breath although I hope to see this kind of tools as
> soon as possible. From what I know about Smalltalk, it's usually
> possible to access the life parsing data and work on the image. In
> common Java environments (apart from VAJ) you'd have to parse everything
> yourself.
Yes, but parsing technology is well-understood these days.
> > My point, however, is that if you need interfaces up front, then of
> > course you should create them. The other position is that you should
> > create an interface for _every_ class, since you may need it one day.
> > That's the kind of crystal-ball gazing that XP is against.
>
> I know of no-one who creates an interface for each class up front. And
> AFAIR (don't have my copy handy) Coad ("Java Design") doesn't advocate
> this.
No, he doesn't come right out and say that. Nevertheless, his examples
are full of interfaces that aren't actually used for anything. And
anyway, if you're arguing in favour of creating interfaces when there's
no current need for them (as Coad does), why _wouldn't_ you create an
interface for (at least practically) every class you write? If you're
not arguing that, then you, I, and XP are in agreement, it seems.
> I regularly work in a way that I start out with a concrete class, even
> if I know that it will get an interface on top of it later on. When I
> write a second class implementing the same implied interface I extract
> the interface.
I think that's exactly the right way to do it. It would be nice if we
could spec our designs down to the last detail before writing a line of
code, but the fact is that it rarely works that way. Sometimes it takes
writing code to realise what the interface/superclass should look like.
Mark Wilden
Whereas I tend to use the simplest solution first, and generalise if and
when that makes subsequent efforts simplest.
It's really just a question of how good one is at predicting the future.
There are times when that's quite possible. Most of the time, it's not,
so why devote effort to solving problems that will probably never arise?
Michael Schuerig
> Michael Schuerig wrote:
> >
> > Mark Wilden <ma...@mwilden.com> wrote:
> >
> > > But you wouldn't use X as the name for the interface, but for the
> > > implementation.
> >
> > Of course, I would! "X" is the name of an interesting abstraction in my
> > problem domain.
>
> Take the example I gave before (or any of Coad's examples): a Customer
> has a name, therefore conforms to the IHasName interface (Coad also
> believes in the I prefix, which I can buy). There may be many other
> interfaces it conforms to, as well. So in the general case, the
> interface won't have the same name as the class.
Incidentally, in my current project I have an interface NamedObject.
Offhand I don't know if I absolutely need it, but in general I like it
to be able to deal with objects at the level of the most general type
possible for a given purpose.
I don't at all like naming conventions that differentiate interfaces and
classes. At any point after creation of an object it doesn't matter
whether I'm referring to it though a class-typed or interface-typed
variable.
[Java refactoring tools]
> > I'm not holding my breath although I hope to see this kind of tools as
> > soon as possible. From what I know about Smalltalk, it's usually
> > possible to access the life parsing data and work on the image. In
> > common Java environments (apart from VAJ) you'd have to parse everything
> > yourself.
>
> Yes, but parsing technology is well-understood these days.
In principle it is. Still it's easier to tap into the same parser used
by your compiler than to roll your own. So far, I have seen only pretty
few refactoring tools for Java. I have seen lots of discussion though.
This indicates that writing such tools might be somewhat more
complicated than first appearances suggest.
> No, he doesn't come right out and say that. Nevertheless, his examples
> are full of interfaces that aren't actually used for anything. And
> anyway, if you're arguing in favour of creating interfaces when there's
> no current need for them (as Coad does), why _wouldn't_ you create an
> interface for (at least practically) every class you write? If you're
> not arguing that, then you, I, and XP are in agreement, it seems.
I'd not create one interface per class. Rather I'd create several
interfaces for several classes to capture their commonalities. This may
be a small investment, but it's easier to remove it later when it's not
needed than to introduce it in cases I do need it.
elidan1
there was some meaning to the name. NamedObject sounds kind of
generic to me, unless, of course it's an abstraction for some
"naming" activity.
I think refactoring and frequent testing as espoused by both
Fowler and Beck are great, but when it comes to naming
conventions, it's time to defer to the JLS:
"...DRAFT
... names of interface types should be short and descriptive,
not overly long, in mixed case with the first letter of each word
capitalized. The name may be a descriptive noun or noun phrase,
which is appropriate when an interface is usedas if it were an
abstract superclass, such as interfaces java.io.DataInput and
java.io.DataOutput; or it may be an adjective describing a
behavior, as for the interfaces java.lang.Runnable and
java.lang.Cloneable."
elidan1
for mail null IS null
nulle...@nullzahav.net.il
Mark Wilden
>
> Incidentally, in my current project I have an interface NamedObject.
> Offhand I don't know if I absolutely need it, but in general I like it
> to be able to deal with objects at the level of the most general type
> possible for a given purpose.
That's fine if it costs zero effort. In practice, though, generality
comes with a price. I'd also ask when you'd assign to a NamedObject
object. If you don't, what's the point of the interface?
That said, I certainly wouldn't say that implementing NamedObject was
that big a drain on resources. The only possibility is that it may make
some poor maintenance programmer scratch his head and ask 'why did he do
that??' :)
> I don't at all like naming conventions that differentiate interfaces and
> classes.
I can see pluses and minuses. Certainly, it doesn't follow the SDK to
use an I prefix.
> In principle it is. Still it's easier to tap into the same parser used
> by your compiler than to roll your own.
That's actually one of Fowler's refactoring tools. Make a change, then
compile to see what broke. :) Seriously, there are changes that you are
safe in making because you can know the compiler will catch them and
present the problems to you to fix.
> I'd not create one interface per class. Rather I'd create several
> interfaces for several classes to capture their commonalities. This may
> be a small investment, but it's easier to remove it later when it's not
> needed than to introduce it in cases I do need it.
In my development, there isn't a single hour I can afford to spend that
isn't directly related to getting the product out the door. Any hour I
spend on trying to second-guess the future could be spent adding a
feature that the customer really cares about. And that's the name of the
game, isn't it?
Michael Schuerig
> In article <1ebcu0f.12o25d01mtwqhyN%schu...@acm.org>,
> schu...@acm.org (Michael Schuerig) wrote:
> >Incidentally, in my current project I have an interface NamedObject.
> >Offhand I don't know if I absolutely need it, but in general I like it
> >to be able to deal with objects at the level of the most general type
> >possible for a given purpose.
> >
> >I don't at all like naming conventions that differentiate interfaces and
> >classes. At any point after creation of an object it doesn't matter
> >whether I'm referring to it though a class-typed or interface-typed
> >variable.
> But it will do wonders to readability and maintainability if
> there was some meaning to the name. NamedObject sounds kind of
> generic to me, unless, of course it's an abstraction for some
> "naming" activity.
public interface NamedObject {
String getName();
void setName(String newName);
}
What more do you want?
> I think refactoring and frequent testing as espoused by both
> Fowler and Beck are great, but when it comes to naming
> conventions, it's time to defer to the JLS:
> "...DRAFT
> ... names of interface types should be short and descriptive,
> not overly long, in mixed case with the first letter of each word
> capitalized. The name may be a descriptive noun or noun phrase,
> which is appropriate when an interface is usedas if it were an
> abstract superclass, such as interfaces java.io.DataInput and
> java.io.DataOutput; or it may be an adjective describing a
> behavior, as for the interfaces java.lang.Runnable and
> java.lang.Cloneable."
I don't see a contradiction. Do you?
Michael Schuerig
> Michael Schuerig wrote:
> >
> > Incidentally, in my current project I have an interface NamedObject.
> > Offhand I don't know if I absolutely need it, but in general I like it
> > to be able to deal with objects at the level of the most general type
> > possible for a given purpose.
>
> That's fine if it costs zero effort. In practice, though, generality
> comes with a price. I'd also ask when you'd assign to a NamedObject
> object. If you don't, what's the point of the interface?
I use it as a mixin for several other interfaces and classes. And I'd
like to capture their commonality. At this low price it's justified for
me.
> In my development, there isn't a single hour I can afford to spend that
> isn't directly related to getting the product out the door. Any hour I
> spend on trying to second-guess the future could be spent adding a
> feature that the customer really cares about. And that's the name of the
> game, isn't it?
Judging by the number of your recent postings I'm hard pressed to
believe this... ;-)
SCNR,
elidan1
schu...@acm.org (Michael Schuerig) wrote:
>elidan1 <elidan1...@zahav.net.il.invalid> wrote:
>
>> In article <1ebcu0f.12o25d01mtwqhyN%schu...@acm.org>,
>
>> >Incidentally, in my current project I have an interface
NamedObject.
>> >Offhand I don't know if I absolutely need it, but in general
I like it
>> >to be able to deal with objects at the level of the most
general type
>> >possible for a given purpose.
>> >
purpose of such an interface ? If you need a generic way to refer
to objects, why not just Object ? What is the benefit of all
objects having a String name attribute and two extra method
implementations ? Could be something specific to your project, or
am I missing something here ?
Mark Wilden
>
> I use [a NamedObject interface as a mixin for several other interfaces
> and classes. And I'd
> like to capture their commonality. At this low price it's justified for
> me.
But if you don't actually use it (by using it as the type of a
variable), I can't see what it provides, except as a method of
documentation, which is served simply by javadoc holding a get/set for
name.
> > In my development, there isn't a single hour I can afford to spend that
> > isn't directly related to getting the product out the door. Any hour I
> > spend on trying to second-guess the future could be spent adding a
> > feature that the customer really cares about. And that's the name of the
> > game, isn't it?
>
> Judging by the number of your recent postings I'm hard pressed to
> believe this... ;-)
Smart guy. :) I could be arguing in my spare time...
Michael Schuerig
> In article <1ebd20q.e2557vouoorN%schu...@acm.org>,
> schu...@acm.org (Michael Schuerig) wrote:
> >public interface NamedObject {
> > String getName();
> > void setName(String newName);
> >}
> Just out of curiosity though, what is the
> purpose of such an interface ? If you need a generic way to refer
> to objects, why not just Object ? What is the benefit of all
> objects having a String name attribute and two extra method
> implementations ? Could be something specific to your project, or
> am I missing something here ?
I'm not implementing this interface in every class, of course. Only
where I need it. Yes, it is useful.
Michael
Mark Wilden
>
> I'm not implementing [NamedObject] interface in every class, of course. Only
> where I need it.
I thought you said you hadn't found a need for it yet? Of course, if you
do need it, then it's XP-approved. :)
But I was thinking about this while I was doing some PalmOS programming
in C. It's been about ten years since I touched the language, and it
wasn't pleasant. I found myself wanting to make this a class and that a
class. But when I looked at the problem more closely, I'm damned if I
could come up with a practical reason for some of my desires. It just
_felt_ better to wrap API calls, e.g., in objects.
So even if there isn't a need, strictly speaking, for a particular OOP
feature, sometimes it just feels better to do it that way (habit and
mindset, I suppose). So I won't bug you any more about NamedObject. :)
XP is more serious about spending lots and lots of time building in
flexibility where it's not needed, but that's clearly not the case here.
Jon Skeet
> Dale King wrote:
> >
> > I think you have a flawed understanding of the Decorator pattern.
> > Components added to a Frame are definitely not the Decorator pattern.
>
> Ooops,
>
> You are right. The Decorator contains the 'decorated' inside it, adding
> extra behavior in addition to the object, so each component would not
> be a Decorator of a Frame.
Would it be worth pointing out at this stage that my post was entirely
lighthearted? Alas, I currently know very little about patterns (or at
least, I possibly know things but don't know their names as patterns) - I
just thought that a repainter sounds like a decorator...
--
Jon Skeet - sk...@pobox.com
http://www.pobox.com/~skeet/
Dale King
>
> Dale King wrote:
> >
> > Actually, I am reading Java Design, 2nd Edition by Coad and Mayfield and
> > they are quite critical of the Observer/Observable combination. The main
> > criticisms are that:
>
> I was less impressed. After getting through it, you realise that they
> want everything to have an interface. This flies right against XP, if
> that's any concern.
In reality there is a continuum. At one end there is the extreme of
designing for so much flexibility and reuse that you can't get anything
useful done and the design is completely unmanageable. On the other
extreme is XP saying designing for flexibility is a waste of time, you
won't reuse the code anyway. And like many things the truth is somewhere
in the middle.
You cannot say one extreme or the other is correct. For your own
application code you should probably lean towards the XP end while still
looking for obvious places for designing in flexibility. If you are
desigining a standard library like something in a java.something package
you had better lean to the flexible design side.
XP seems to say that you shouldn't design for reuse because it won't be
reused. And if it is reused you can fix it later because it is not a big
deal. I have found the exact opposite to be true. I have a couple of
priniciples I have arrived at through experience:
- Design for reuse, because despite what you think, it will be reused.
- Design it right the first time, because you won't get another chance.
I have a lot of problem with the idea of saying that change is not a
major problem. The C3 project is listed as a major success for XP. They
were able to build this program from scratch in some short amount of
time. I find that completely irrelavent as a test for a design
philosophy. The true test is after a few years and many changes are
made. Speaking from experience having helped develop software that has
now been modified in many ways far beyond the imaginations of the
original development, it has become quite an unruly mess in certain
areas. Those areas were designed to only meet the current demands.
Changes get made using the same philosophy, just paste in this band-aid
to make it work. I now refer to some of those areas as huge balls of
bandaids and bailing wire. You have to be careful what you touch because
it might all go flying apart. The code is just a bunch of exceptions to
the main logic now. Now part of that is because it is C code, not OO
code. But there are other parts (like the ones I wrote ;-) that are much
cleaner and have stood the test of time very well.
In defense of the book, it is trying to give you techniques for
factoring out interfaces and sometimes has to use some contrived
examples to do so. And it does talk about the tradeoffs. Quoting for the
book (section 3.6.2), "Add in plug-in points [i.e. interfaces] where you
need them, where they pay for themselves by adding flexibility in
exchange for increased model complexity." The paragraph before talks
about whether a more flexible design is better and says, "Yes, _if_ such
flexibility fits within the capability, schedule, and cost constraints
for the project at hand." Sounds compatible with XP to me.
--
--- Dale King
Recruiters: I am not willing to relocate outside of Indianapolis!
Dale King
>
> gmou...@my-deja.com wrote:
> >
> > While I am fairly new to XP, I don't recall anything in Beck's book even
> > mentioning interfaces. Are you trying to say that using interfaces tend to
> > resolve more than the present problem, ie not programming for today?
>
> thinks that class should extend the IHasName interface, just in case he
> ever ends up with two classes that he wants to treat the same WRT names.
> his book.)
Well, I have the book open in front of me and nowhere does it say
antyhing remotely like that. Many of the examples only have 1 or 2
methods to an interface, but that is primarily for brevity. They talk
several times about the tradeoffs between complexity and flexibility.
Section 3.4 (which I should have also quoted in my previous message)
they list possible places you could add interfaces (including an
interface for every method call) and then they say:
"Very flexible? Yes. Very unwieldy? Yes--and that is the problem. If you
set off to build the most flexible software in the universe, you will
most definitely run out of time, budget, and resources before you get
there. 'As flexible as possible' is not a reasonable design objective.
"So where does it make sense to add in an interface? Where should you
invest in designing-in flexibility? Here is a strategy on this very
matter:
"Where to Add Interfaces Strategy: Add interfaces at those points in
your design where you anticipate change: (1) Connect with an interface
implementer rather than with an object in a specific class; (2) Send a
message to an interface implementer rather than to an object in a
specific class; and (3) Invoke a plug-in method rather than a method
defined within a class."
I don't really care whether you agree with that philosophy or whether it
agrees with XP. The point is that you are mischaracterizing the book.
> XP would say that it's quite easy to add the interface later, when and
> if it's ever needed.
Since the book talks about an interface being like a plug or connector,
let's continue that analogy.
Let's use a computer as the analogy. The new XP computer has no plugs on
it whatsoever. The power cord is connected directly, the monitor,
keyboard, mouse, dot matrix printer, and 14.4 modem are all attached
(making it very hard to move around). It is designed this way because we
can save a few dollars and time on not having plugs and all the work of
deciding on a protocol. Later on someone wants a larger monitor, a 56K
modem, a trackball, an ergonomic keyboard, a laser printer, and needs to
run some foreign power. XP says, fine they can cut the cables and solder
on a connector to the cable. But as usual when you don't design
flexibility in, the connection makes assumptions about what it is
talking to (and this is most definitely a common occurrence). It is hard
to come up with an example for the analogy of a computer since they
didn't follow this line of reasoning, but let's say that to save money
on the dot matrix printer, XP didn't put any smarts inside the printer.
The computer controls the print head and paper feed directly. Trying to
now switch to a laser printer is a major problem. You can't just add an
interface. It would be too much of a tear-up now to devise a printer
port that supports both the dumb dot matrix and a laser printer. Now we
have a 12 month design cycle to add a new printer port. Of course we end
up leaving the old printer connection for backwards compatibility. It
will not be long before such a computer is driven out of the
marketplace.
But clearly computers were not designed this way. Manufacturers early on
recognized the benefit to plug and play. Designing a flexible design up
front simplifies the process of making changes.
Mark Wilden
>
> In reality there is a continuum. At one end there is the extreme of
> designing for so much flexibility and reuse that you can't get anything
> useful done and the design is completely unmanageable. On the other
> extreme is XP saying designing for flexibility is a waste of time, you
> won't reuse the code anyway. And like many things the truth is somewhere
> in the middle.
Frankly, I've never bought the 'happy medium' argument. Does that mean
that if someone comes out with something even more extreme than XP, that
XP all of a sudden makes sense? :)
> application code you should probably lean towards the XP end while still
> looking for obvious places for designing in flexibility. If you are
> desigining a standard library like something in a java.something package
> you had better lean to the flexible design side.
I agree, for the reason that XP's claim--change is easy--doesn't apply
to code you distribute widely. XP doesn't address this case, and should.
That said, this doesn't apply to the vast majority of code we write,
which stays under our control.
> XP seems to say that you shouldn't design for reuse because it won't be
> reused.
Not quite. XP doesn't say you shouldn't design for reuse, but that you
shouldn't design for reuse that you don't know anything about. The code
may be reused in ways you can't even dream of. Since you can't even
dream of it, trying to add flexibility to meet that case is 1)
impossible, and 2) a waste of time.
But as for designing for reuse in general, XP doesn't have any problem
with that. You'll find many of Fowler's refactorings address just that
very goal.
> - Design it right the first time, because you won't get another chance.
Whereas in my experience, you get plenty of chances, especially if
you're working to minimal specs that get the product out the door
quickly.
One reason is that users don't know what they want until they see what
you've done. They will _always_ want changes. You will _always_ need to
go back and rethink your design, at least somewhat. Anyone who claims
otherwise is claiming to be a mind-reader.
> I have a lot of problem with the idea of saying that change is not a
> major problem. The C3 project is listed as a major success for XP. They
> were able to build this program from scratch in some short amount of
> time. I find that completely irrelavent as a test for a design
> philosophy. The true test is after a few years and many changes are
> made.
The principals behind XP aren't exactly wet behind the ears. They have
years and years of real-world experience to back up their proposals.
We're not talking about some computer scientists here.
> Speaking from experience having helped develop software that has
> now been modified in many ways far beyond the imaginations of the
> original development, it has become quite an unruly mess in certain
> areas. Those areas were designed to only meet the current demands.
One of XP's points is that frequent refactoring is necessary. Don't just
apply a bandaid--meet the current needs _correctly_.
> In defense of the book, it is trying to give you techniques for
> factoring out interfaces and sometimes has to use some contrived
> examples to do so.
Isn't that soooo common in books? The idea of actually presenting
real-world code seems beyond them sometimes. That's one of the great
things about "Clouds to Code"--real world code on a real world project.
> And it does talk about the tradeoffs. Quoting for the
> book (section 3.6.2), "Add in plug-in points [i.e. interfaces] where you
> need them, where they pay for themselves by adding flexibility in
> exchange for increased model complexity." The paragraph before talks
> about whether a more flexible design is better and says, "Yes, _if_ such
> flexibility fits within the capability, schedule, and cost constraints
> for the project at hand." Sounds compatible with XP to me.
Yeah, I remember that. But then they go on to slap an interface on every
class they write. Pah! :)
Mark Wilden
>
> I don't really care whether you agree with that philosophy or whether it
> agrees with XP. The point is that you are mischaracterizing the book.
That's a little unfair. I did admit that I did not have the book in
front of me, and that I was exaggerating. And my main point about the
book remains: They advocate adding interfaces to meet future changes,
not current requirements. For example:
> "Where to Add Interfaces Strategy: Add interfaces at those points in
> your design where you anticipate change: "
XP would say to add the interface when there _is_ change, not try to
'anticipate' change that you can know nothing about.
> Let's use a computer as the analogy. The new XP computer has no plugs on
> it whatsoever. The power cord is connected directly, the monitor,
> keyboard, mouse, dot matrix printer, and 14.4 modem are all attached
> (making it very hard to move around). It is designed this way because we
> can save a few dollars and time on not having plugs and all the work of
> deciding on a protocol.
The problem with that analogy is that that design doesn't meet _current_
needs. If two different power sources had not been invented yet, it
would be foolhardy to design a computer to meet that 'need'. But since
there is more than one power source, it makes good sense to allow for
it.
Same with the printer. If there were only one printer type in the world,
it wouldn't make sense to predict that some day there might be, hence
you should use an interface. But given that there is more than one
printer type, a good computer meets _current_ needs by being adaptable.
> But clearly computers were not designed this way. Manufacturers early on
> recognized the benefit to plug and play.
They did not! :) The builders of the first computers (and the second
computers, and so on until very recently) recognised no such benefit.
Now that there's money to be made in plug 'n play, manufacturers support
it.
Dale King
Mark Wilden wrote:
>
> Laurence V wrote:
> >
> > On Sat, 27 May 2000 19:18:20 +0100, Mark Wilden <ma...@mwilden.com> wrote:
> >
> > I do always ask myself the question
> > "Would an interface make sense here? Would the use of an interface sow the seed for later reuse in this and similar
> > cases?"
Which is what Coad and Mayfield are advocating. They do not say make an
interface for every class.
> Whereas I tend to use the simplest solution first, and generalise if and
> when that makes subsequent efforts simplest.
>
> It's really just a question of how good one is at predicting the future.
> There are times when that's quite possible. Most of the time, it's not,
> so why devote effort to solving problems that will probably never arise?
Because you are wrong. It almost always arises. If you are creating
software one-time and can unload it and never have to look at it again
maybe it doesn't arise for you. If you have to go on supporting software
and making changes to it, adapting it to new uses, it arises repeatedly.
Every software engineer will tell you that it is a whole lot cheaper and
easier to lay the groundwork for that future change now.
And it usually isn't that hard to contemplate ways in which it could
change in the future. The more you design in the flexibility the easier
it becomes.
I also see the question of interfaces as one of coupling. An interface
helps you to isolate your code from one another. The less this class
knows about another the better. Designing without interfaces leads to
too much familiarity and reliance on another class. You indicated that
all you had to do was mechanically add interfaces when needed and it is
rarely if ever that simple later on. It can be if the designers are
disciplined enough to avoid this familiarity between classes, but it is
rare to maintain that kind of discipline. Intefaces let you enforce that
discipline.
Mark Wilden
>
> Which is what Coad and Mayfield are advocating. They do not say make an
> interface for every class.
They don't say it, but they sure seem to do it in their examples! What
they don't do is use interfaces only where they are needed. They use
them in case they are needed.
> Because you are wrong. It almost always arises. If you are creating
> software one-time and can unload it and never have to look at it again
> maybe it doesn't arise for you. If you have to go on supporting software
> and making changes to it, adapting it to new uses, it arises repeatedly.
I've been really obscure if I haven't made clear before now that XP (and
I) firmly believe that change is inevitable. No one's talking about
'one-time' code. XP is the most change-oriented method I've ever come
across.
> Every software engineer will tell you that it is a whole lot cheaper and
> easier to lay the groundwork for that future change now.
Sure, if you can predict what that change will be. If you can't, then
how do you know what groundwork you should be laying? (Mind you, there
are plenty of commonly accepted ways of making code easier to change
that don't involve trying to predict the future.)
> And it usually isn't that hard to contemplate ways in which it could
> change in the future. The more you design in the flexibility the easier
> it becomes.
I'll go along with that. Certainly, if you designed for 100 future
changes, the five changes that actually occur that you foresaw will be
easier to deal with. Of course, the other 95 changes that you designed
for but never happened are wasted effort. And you still have to change
your code to accommodate the 50 changes that you didn't foresee.
> I also see the question of interfaces as one of coupling. An interface
> helps you to isolate your code from one another. The less this class
> knows about another the better. Designing without interfaces leads to
> too much familiarity and reliance on another class. You indicated that
> all you had to do was mechanically add interfaces when needed and it is
> rarely if ever that simple later on. It can be if the designers are
> disciplined enough to avoid this familiarity between classes, but it is
> rare to maintain that kind of discipline. Intefaces let you enforce that
> discipline.
Maybe that's the real issue, here. XP doesn't work well if people need
discipline enforced upon them. It assumes that our classes already have
nicely decoupled interfaces. So tacking on a Java interface doesn't buy
anything, unless you have a present need for having two classes present
the same face.
But I'd hardly call myself the world's leading expert on XP. Maybe we
could postpone this debate until you've read "Extreme Programming
Explained" and "Refactoring", where some people who really know what
they're talking about explain why they think designing for future change
is a bad idea.
Michael Schuerig
> I've been really obscure if I haven't made clear before now that XP (and
> I) firmly believe that change is inevitable. No one's talking about
> 'one-time' code. XP is the most change-oriented method I've ever come
> across.
> Maybe that's the real issue, here. XP doesn't work well if people need
> discipline enforced upon them.
> But I'd hardly call myself the world's leading expert on XP. Maybe we
> could postpone this debate until you've read "Extreme Programming
> Explained" and "Refactoring", where some people who really know what
> they're talking about explain why they think designing for future change
> is a bad idea.
Mark,
in much of what you've written you're talking as if you indeed *had*
that experience. Including all of the practices such as PairProgramming,
DoTheSimplestThingThatCouldPossiblyWork, OnceAndOnlyOnce,
YouArentGonnaNeedIt, UnitTests, RefactorMercilessly and others whose
names I keep forgetting.
I don't mean to be overly harsh, but IMHO you're doing XP a disservice
by talking overly enthusiastically about while lacking the respective
experience. I'm taking the judgment of others, who I know to be
practicing XP, a lot more serious.
Mark Wilden
>
> in much of what you've written you're talking as if you indeed *had*
> that experience. Including all of the practices such as PairProgramming,
> DoTheSimplestThingThatCouldPossiblyWork, OnceAndOnlyOnce,
> YouArentGonnaNeedIt, UnitTests, RefactorMercilessly and others whose
> names I keep forgetting.
The only XP method I haven't used is pair programming. I've been using
the rest of it for over a year, including leading a team and educating
them in the practice.
> I don't mean to be overly harsh, but IMHO you're doing XP a disservice
> by talking overly enthusiastically about while lacking the respective
> experience.
Nonsense. I don't expect any intelligent person to read a post and say,
hmmm...he seems to know what he's talking about, I'd better do what he
says! I've been explaining the benefits of XP in a logical way, not as
some kind of evangelist. The points I've made can be answered in a
logical way, not in an ad hominem attack on my experience (which fails).
> I'm taking the judgment of others, who I know to be
> practicing XP, a lot more serious.
Well, when you actually get around to reading one of the XP books, I'll
be fascinated to hear of the points I've made about XP that they
disagree with.
I think discussions on technical forums should be about technical
issues, not about people. I happen to make a self-deprecatory remark
about not being the world's greatest expert on XP (which I'm not), and
you've decided to use that as an attack.
(I see you've set follow-ups to a newsgroup I can't access,
unfortunately. Therefore, I'm sending this back to where I entered it.)