For a few years now my most common refactoring was Extract Method. Got a big method? Extract sub methods. Got a deeply nested method? Extract each level into a new method. Got any other problem? You should probably look for methods to extract.
I've change my mind; these days I'm all about Extract Class, or more accurately Replace Method With Class. Got a big method? Cut out it's body and paste it into a new method on a new class. Got a deeply nested method? Well... I guess Extract Method still works better for that one. Got any other problem though? Just pick the largest method (or #region for you C# folks) and extract it to a new class.
Why the sudden change of mind? Recent real world experience that is best explained with bulleted lists within a matrix:
Extract Method | Extract Class | |
---|---|---|
Mess | Unless there's a lot of duplication that you can quickly remove, the class size stays about the same. | Immediately reduces the class size by moving code to a new class. The compiler will tell you what it depends on and what depends on it. |
Power | You get a new method:
|
You get a new class:
|
Concepts | Small, local, procedural:
|
Large, project-wide, object oriented:
|
or, in prose form: Extract Class immediately reduces the amount of code you have to worry about, improves cohesiveness of the remaining class, and gives you familiar object oriented techniques to work with.
Of course it's good to see if related methods could be extracted into a new class after extracting a method and it's probably good to break up the monster method after hiding it in a new class. I just found it much easier to make progress when I relied on extracting large methods to new classes first.
To be fair, you can also override new methods; and pass them around. ;)
ReplyDeleteI actually don't mind overly long methods or classes, so I say: do whatever works for your needs-- there really is no right way, but there are working and non-working projects!
Ebyan "Nolithius" Alvarez-Buylla
http://www.nolithius.com
True; there may not be a right or wrong way but it's always a good day when I find a "more right" way that makes it easier to go from non-working to working software. Although I'll probably change my mind a few years from now....
DeleteI don't know.
ReplyDeleteIn large project at work (GIS systems), large classes are results of using big and dictate frameworks, where you cannot move too much outside. Refactor methods seems to be right choice for my kind of project, because I already have too much classes.
You can say: you have IDE (Eclipse in my case): right! But I have colleague worked in this project for many years (12 people in 4 years so far, now 3 still active). If I refactor too much, what I need is documentation and... documentation is always a problem for a programmer. I don't want to make a revolution in my code, just let him be more readable.
Tip for the future: maybe I can jsut refactor and extrac in some classes little portion of code, not in "core" classes? And start from that? I will think about that, thanks!