"Split Class" refactoring?
For a while now, I've been thinking a refactoring I've never seen would be useful. Tell me if it's a good idea, or if it just means my style of coding is too chaotic and I'm crazy :-)
I'll take a concrete case: When I was developing the new Output Window for NetBeans, I had a class that represented an output buffer, with methods for reading/writing data, getting offsets and line counts, etc.
Then I implemented line-wrapping. To make that fast, I started keeping some data about how many on-screen lines a "line" of data mapped to. The class progressively grew more hair as the wrapping code got more and more heavily optimized. At the end I had FrankenBuffer, with its buffer-related lines, and a whole bunch of methods relating to line wrapping (sometime I'll have to write a blog about how to do obscenely scalable line wrapping code - there are some neat optimizations you can do if you know the buffer only grows at the end, etc. Lots of fun with primitive int arrays and binary searches. Suffice it to say, yes, I did want the line wrapping code very close to the buffer code).
So what I needed was to factor all of the buffer stuff into another class, and delegate where needed. I even shopped the competition and checked out other IDEs, but didn't find anything that was really what I was looking for - you can do it in a hackish sort of way by first generating a superclass, then replacing inheritance with delegation, but it's somewhat painful.
Anyway, have other people been in this position? I have a feeling a "Split Class" refactoring would be pretty useful - but it could also be an artifact of the way I code - maybe the rest of the world wouldn't find it all that useful. Let me know.
Now, what would be really slick is if such a refactoring actually detected if there were certain sets of methods that did/did not touch certain member variables and made a good guess of one or more optimal ways to split the class without breaking anything.