> > No I don't think so! I have no inheritance!!!!
> Yes, sure. I think this could be done by "Extract Interface" and THEN
> "Replace Inheritance with Delegation".
Yes, that makes sense, but sounds like as much work as cutting the
methods out and pasting them into a new interface ;-)
I just would have thought that a simple checkbox for "make this
class/interface implement/extend the extracted interface" would be a
simple solution that adds functionality and puts on the path of "least
unexpected behaviour".
> > I haven't read the book "Refactoring" yet, but I will. However I don't
> > think you should follow this publication as religiously as you seem to.
> >
> > How about doing things that are intuitive and make sense, rather than
> > adhering to a "standard" invented by a single person's book?
> What?? That we don't do absolutely!
OK, I take your points and thanks for the info � it's just that all I
seem to hear are references to the book ;-)
[snip]
> As you said:
> "I am using aggregation in the interfaces, instead of inheritance. i.e. I
> also added a getExtractedInterface() method to the source interface."
> this is exactly what is named "delegation". You delegate some
functionality
> to another class/interface.
I understand that. My point was that I didn't even consciously think of
the switch to aggregation/delegation when I did it � I was doing what
comes naturally ("Extract interface") and possibly would not have chose
"Extract interface and delegate" or a two-step process because at the
time I was running on auto-pilot.
After years of doing them, you don't need to consciously think about
these things as processes before you do them � often only in
post-analysis do you put names to what you did.
Of course we need names for the functions...
> > So, with these convoluted complicated names for
> > features, people may not understand them unless they have read this book.
> Well, we should have at least some names. If there is no pretty obvious
> name, it's better to use name from the book, then it will be familar to
at
> least some people..
Yes, agreed. That's good. Right now though � to me � "Extract Interface"
is not quite what it sounds. It is "Extract and implement interface"
really.
> > (In which case I hope you are getting royalties on sales)
> We don't.
I didn't really think you did :-)
> > For example, the current "Introduce Field" is counter-intuitive to me
> > personally. Any normal person I think will assume from the name that this
> > means you can highlight an undefined variable or an expression and
> > convert it to a field of the class. Not so. I still can't work out how
> > that feature works.
> Yes, it actually works in this way. Just select an expression in code and
> invoke "Introduce Field" to create a new field initialized by this
> expression. Pretty similar to "Introduce Variable". Doesn't it work for
you?
Not as far as I can tell. I've never got it to do anything successfully.
It always pukes on my selection.
> > Yes I've been told that it works according to the
> > book's description of that refactoring, but what use is that to me? That
> > doesn't make it intuitive.
> AFAIK, there is no such refactoring in Martin Fowler's book.
...Er ok.
Cheers
_______________________________________________
Eap-list mailing list
[EMAIL PROTECTED]
http://www.intellij.com/mailman/listinfo/eap-list
