Refactoring, prefactoring, defactoring

I’m fond of Kent Beck books on refactoring issues (Refactoring: Improving the Design of Existing Code, Implementation Patterns). Reading these books makes me more critic when looking to my own code. Most of the time I can catch signs of need for factoring something into new structures.

Refactoring

A common tool of refactoring are the property names. As soon as you can see a particular word (mostly a prefix) appear more often, you can extract those matching properties into a new object (probably named after the common prefix).

// When you see this.
@property (nonatomic) CGFloat strokeWidth;
@property (nonatomic, strong) UIColor *strokeColor;
@property (nonatomic, strong) NSArray *strokeDashPattern;
// You can create something like this.
@interface Stroke : NSObject
@property (nonatomic) CGFloat width;
@property (nonatomic, strong) UIColor *color;
@property (nonatomic, strong) NSArray *dashPattern;
@end

Next method that occurs on a regular basis is the “interface size” of a particular class. If a particular class happens to be to “external”, when too many inner property seems to be defined as publicly available for clients, then we can wrap all the implementation details that uses those properties into a new method. Clients now need access only to this wrapped method. We can revise the communication flow between the objects, and bind values that are really cruitial to carry out that particular feature.

We can traverse those values through that method, so the original class became more encapsulated, also the client code get more clean. The method name will probably describe the feature. After all, instead of having a bulk of properties exposed to clients we will have a really descriptive method that really improve the readability of our code.

// Example.

Having all the refactoring principles in mind, sometimes I lay out a code design almost refactored in advance, already split into role classes even without a single line of implementation code.

Prefactoring

This turned out not to be a good approach, actually it cannot be. To refactor something, you must get know its weak points, and without a functional body there is nothing to spot. When coding like this I often found myself surrounded with dozens of tiny classes sometimes with only a few properties at all, hooked up along many redirections. A structure that is split into too many pieces tends to be also unmanagable / hardly maintainable. Not that unmanagable than a so called spagetthi, but not optimal for sure. This is something I called prefactoring, and lately I force myself to avoid such a pattern.

Defactoring

Right after I realize that there are too many pieces I start to group some player into grouped structures. This is defactoring. They can live there up to a point where it grows too big, then it is a pretty convenient time to refactor it along the shaped dependency patterns.

Not easy to spot all the break even points throughout the lifecycle of a project, this is something like “the way of a developer” or something. Fortunately xCode supports these kind of flexible workflow as it keep indexing all the code, also provides tools to extract code and lift it along class hierarcy.

As it happens really often, variable names are the best signs of these code smells. A simple refactoring can be taken place when you see a word too often among your variable names as a prefix /suffix, so you can see the need for a new class that embodies those features.

…be continued, keep writing this…

DISCLAIMER. THE INFORMATION ON THIS BLOG (INCLUDING BUT NOT LIMITED TO ARTICLES, IMAGES, CODE SNIPPETS, SOURCE CODES, EXAMPLE PROJECTS, ETC.) IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE INFORMATION ON THIS BLOG (INCLUDING BUT NOT LIMITED TO ARTICLES, IMAGES, CODE SNIPPETS, SOURCE CODES, EXAMPLE PROJECTS, ETC.).

Become a Patron!
  • Phil

    I thought the concept of “prefactoring” was silly when a colleague brought in a programming book by that title. When I was an undergrad, in my systems analysis class, we simply called it “factoring..”