K. Cassell | 14 Mar 2010 21:15
Picon
Favicon

Chatting about Extract Class

I'm curious about how other people view the Extract Class refactoring.  For instance, do you use it much, how
do you go about it, what would help you do it more often?

In my case, I extract methods all the time, but extract classes much less often.  There are a couple of
reasons.  First, there isn't as much opportunity to extract classes - there are a lot more classes than
methods.  But secondly, it's hard.  It's not easy to decide what belongs in the new classes, and the tool
support isn't as good.

Usually for my code, I decide to extract a class when it gets above a certain size, and I feel embarrassed that
I let it get so big.  I typically have a fair idea of where I should split it.  For other people's code, it's
worse.  It usually isn't obvious to me where it should be split.  Generally, I would look for semantic clues
for common function, e.g. look for method identifiers that have common parts.  For example, if there were a
lot of methods with "XML" in the name, I might look into making some kind of XML helper class.

For actually performing the refactoring, I much prefer to use tools.  Of the ones I know about for Java, I like
IntelliJ's IDEA the best, even though I am an Eclipse user.  Eclipse 3.5.1 basically just let me pull out
fields into a new class; IntelliJ let me pull out both fields and methods.  Unfortunately, IntelliJ's
implementation was buggy.  My extracted classes often had compile errors.  However, these were generally
easy to fix, and I felt that IntelliJ was doing a lot more for me than it was doing to me.  ;)

Without tools, I seldom try to extract classes from other people's code.  Generally, it seems to be too much
work for too little result.  Some might call me lazy.  I prefer "analytical".  :)

I'm interested in hearing your opinions/war stories.

Regards,
Keith Cassell

------------------------------------

(Continue reading)

Adam Sroka | 15 Mar 2010 00:42
Picon
Gravatar

Re: Chatting about Extract Class

On Sun, Mar 14, 2010 at 1:15 PM, K. Cassell <kcassell2001 <at> yahoo.com> wrote:
>
>
>
> I'm curious about how other people view the Extract Class refactoring. For instance, do you use it much,
how do you go about it, what would help you do it more often?
>

I do it all the time. Large classes that violate SRP are one of the
most common smells in legacy code, and they also crop up a lot any
time you add new behavior to existing classes.

> In my case, I extract methods all the time, but extract classes much less often. There are a couple of
reasons. First, there isn't as much opportunity to extract classes - there are a lot more classes than
methods. But secondly, it's hard. It's not easy to decide what belongs in the new classes, and the tool
support isn't as good.
>

Extract class is more related to move method than to extract method.
Most refactoring (other than renaming things), in my experience, is
either about moving things around to make sure the class has a single
responsibility, or it's about composing methods so that they are
small, clear, and focused. Extract class and move method are common
refactorings for the former. Extract method and inline method are
common refactorings for the latter.

> Usually for my code, I decide to extract a class when it gets above a certain size, and I feel embarrassed
that I let it get so big. I typically have a fair idea of where I should split it. For other people's code, it's
worse. It usually isn't obvious to me where it should be split. Generally, I would look for semantic clues
for common function, e.g. look for method identifiers that have common parts. For example, if there were a
(Continue reading)

J Arrizza | 17 Mar 2010 01:43
Picon

Re: Chatting about Extract Class

> I'm curious about how other people view the Extract Class refactoring. For
instance, do you use it much, ...

I don't think it's about "how often?" as it is of "which is more
important?". You will Extract Methods more often (5x? 10x?) but it's usually
a stepping stone to an Extract Class refactoring. In general the flow looks
like:

      - extract method 1 as a private method
            ...
     - extract method n as a private method
     - extract a subset of the private methods into a class and make them
public.
     - add UTs around the new class
     - refactor  the new class if necessary (rename is usually the common
one at this point)
     - repeat

At some point the original class is "bare bones" or "minimal" or "singular"
or "focused" or whatever you use to describe a final, well-defined, class.
Usually the class becomes static then and does not change for a very long
time (normally only if an enhancement is added to it).

The extract class refactoring is more important because it is one of the
final steps in a better OO design. The extract method just simplifies the
original class enough to get you to the point where you can do the extract
class.

(Note this is all generally speaking, there are exceptions everywhere in the
process)
(Continue reading)

Richard | 17 Mar 2010 23:41
Favicon
Gravatar

Re: Chatting about Extract Class


In article <2ef359581003141642n42f109b9o2c3faadcca54c1f9 <at> mail.gmail.com>,
    Adam Sroka <adam.sroka <at> gmail.com>  writes:

> I have used IDEA's extract class refactoring, I have also used
> Eclipse's (And the one in ReSharper for C#). As often as not, though,
> I create the new class and move members there as separate steps. That
> works better in some circumstances.

Reading the documentation for ReSharper's "Extract Class From
Parameters" it doesn't quite seem like Extract Class from Fowler to
me.  Is that the one you used, or did you use something else?  I
looked at the 4.5 documentation on their web site.  I haven't used
this particular refactoring from ReSharper before.

> I don't always use an IDE. In fact I've written a lot of code in Ruby,
> Perl, and Python and I generally just use emacs for those. I don't use
> a lot of advanced features in emacs, and I mostly refactor by hand. I
> take small steps and run the tests a lot.

That last bit is important for large manual refactorings.  When faced
with one of those, I definately think about how I can do things in a
series of steps, such as your suggestion of creating a new empty class
and moving methods one at a time.
--

-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
 <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

      Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

(Continue reading)

Adam Sroka | 22 Mar 2010 04:25
Picon
Gravatar

Re: Chatting about Extract Class

On Wed, Mar 17, 2010 at 3:41 PM, Richard <legalize <at> xmission.com> wrote:
>
>
>
> In article <2ef359581003141642n42f109b9o2c3faadcca54c1f9 <at> mail.gmail.com>,
>
> Adam Sroka <adam.sroka <at> gmail.com> writes:
>
> > I have used IDEA's extract class refactoring, I have also used
> > Eclipse's (And the one in ReSharper for C#). As often as not, though,
> > I create the new class and move members there as separate steps. That
> > works better in some circumstances.
>
> Reading the documentation for ReSharper's "Extract Class From
> Parameters" it doesn't quite seem like Extract Class from Fowler to
> me. Is that the one you used, or did you use something else? I
> looked at the 4.5 documentation on their web site. I haven't used
> this particular refactoring from ReSharper before.
>

 I recently started using the beta version of 5.0, but it doesn't have
a true "Extract Class" refactoring either.

I thought I recalled using something more like Eclipse's Extract Class
wizard in C#, but it appears I was mistaken. Actually, even moving a
method is a bit of a pain in the butt in C#, but ReSharper can be
quite helpful.

------------------------------------

(Continue reading)

mokh.brain@ymail.com | 24 Mar 2010 10:45
Favicon

Pro*C Code Refactoring

Hi all,
Can you indicates to me if there's tools of Pro*c Code refactoring

The Input code is Pro*c
The output code is C++

Best regards

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/refactoring/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/refactoring/join
    (Yahoo! ID required)

<*> To change settings via email:
    refactoring-digest <at> yahoogroups.com 
    refactoring-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    refactoring-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
(Continue reading)

Lehmia Kirn | 20 Mar 2010 08:44
Picon
Favicon

moreUnit Plugin

Any one who has used MoreUnit plugin of eclipse.Kindly reply me in 
person.I need help in initiating move method refactoring.
And FYI

"MoreUnit is an Eclipse plugin that should assist with writing more unit tests.
It can decorate classes which have testcase(s) and mark methods in the editor
which are under test.  Renaming/moving classes/methods will cause moreUnit to
rename/move the corresponding test code.  Generation of test method stubs is
also possible."  http://sourceforge.net/projects/moreunit/

Regrads
Lehmia

[Non-text portions of this message have been removed]

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/refactoring/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/refactoring/join
    (Yahoo! ID required)

<*> To change settings via email:
(Continue reading)

Hameed, Mudassir (Gale | 15 Mar 2010 15:31
Favicon

RE: Chatting about Extract Class

I do extract into classes at times. But whether you extract into classes or methods, it's a good idea to get
the code under unit test coverage before you refactor.

One way to decide whether you need a new class is to look at the name of the class. XMLHelper for example can
"help" in so many ways. These types of classes should ideally be broken down further. XMLParser on the
other hand has just one function, to parse. Similarly URLHelper vs. URLExtractor, DatabaseUtil vs.
DatabaseConnector or DataRetriever.

Mudassir Hameed
Gale | Cengage Learning

________________________________
From: refactoring <at> yahoogroups.com [mailto:refactoring <at> yahoogroups.com] On Behalf Of K. Cassell
Sent: Sunday, March 14, 2010 4:16 PM
To: refactoring <at> yahoogroups.com
Subject: [refactoring] Chatting about Extract Class

I'm curious about how other people view the Extract Class refactoring. For instance, do you use it much, how
do you go about it, what would help you do it more often?

In my case, I extract methods all the time, but extract classes much less often. There are a couple of
reasons. First, there isn't as much opportunity to extract classes - there are a lot more classes than
methods. But secondly, it's hard. It's not easy to decide what belongs in the new classes, and the tool
support isn't as good.

Usually for my code, I decide to extract a class when it gets above a certain size, and I feel embarrassed that
I let it get so big. I typically have a fair idea of where I should split it. For other people's code, it's
worse. It usually isn't obvious to me where it should be split. Generally, I would look for semantic clues
for common function, e.g. look for method identifiers that have common parts. For example, if there were a
lot of methods with "XML" in the name, I might look into making some kind of XML helper class.
(Continue reading)

K. Cassell | 18 Mar 2010 21:05
Picon
Favicon

Re: Chatting about Extract Class

--- In refactoring <at> yahoogroups.com, J Arrizza <cppgent0 <at> ...> wrote:
>
> Three basic ways:
> 
> 1) ... look for associations between a subset of methods and
> one (or perhaps a few) instance variables. ...
> 2) Look for commonality in the method signatures...
> 3) Sheer luck. I see a pattern in the names of the methods, or some
> commonality in how they behave, or a commonality in the instance variables,...

I like your list and explanation.  These (especially 1) also correspond well with certain OO cohesion
metrics.  In addition to these, I can think of the following:

4) Parts of my class make calls out to a small set of external methods.  For example, if only certain methods
call methods in java.io.*, maybe these should be extracted.
5) External classes appear to call certain subsets of my class.

Of these, I probably do 1, 3, and 4 the most.  Of course, there is overlap, and this makes things easier.  If you
have methods with "write", "file", etc. in the names, and they have File arguments, and they make calls to
java.io, and they all interact, and they all have comments "//TODO extract me into a new class" ;^)  ...,
then maybe extracting a class would be an especially good idea.

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/refactoring/

<*> Your email settings:
(Continue reading)


Gmane