Reader Comments (Page 1 of 1)

When I re-factor code, it is typically because I have thought of a better design or the existing design will not scale. I suppose I also rename variables and methods or add and remove method arguments, but those sorts of re-factoring can be handled with a good text editor, FileMerge.app, and global replace capability.

I theorize Objective-C and Cocoa require less re-factoring because of the following in no particular order.

1) I accomplish the same goals with a lot less code using Cocoa. The fact Core Data models do not strictly have to generate code and bindings often require no code and Interface Builder does not generate code results in a lot less code. Steve Jobs used to say something like the following: "It doesn't matter whether a human or a computer generates the code; every line of code is a potential bug and a potential source of future maintenance" Every line of code is also a potential re-factoring target.

2) I subclass a lot less with Cocoa. One of the most common reasons to re-factor is to change an inheritance hierarchy. For example, if B is a subclass of A, I might decide that there are reusable features in B that really should have been in am intermediate class and end up with B is a subclass of C which is a subclass of A. B->A becomes B->C->A. With Objective-C, I can add methods to base classes using categories instead of subclassing. Cocoa uses ubiquitous delegates and notifications which reduce subclassing. See http://www.stepwise.com/Articles/Technical/2000-03-03.01.html and http://www.stepwise.com/Articles/Technical/CategoricallySpeaking.html With fewer subclasses (and fewer classes total), there is less re-factoring.

3) Another reason to re-factor is to move methods and instance variables up and down in an existing inheritance hierarchy. I find it easier/more convenient to make such changes using Core data and categories than out traditional code re-factoring.

4) Achieving good separation of concerns is another reason to re-factor. Categories really help with this. As an example, I have a 3D engine that uses a data structure called a QuadTree to organize objects of type EBNQuadElement in a scene. The QuadTree is part of the Model (as in MVC) and is implemented in a shared library. The exact same Model is used in several applications, most of which used OpenGL to render and one of which uses Direct X to render. In the OpenGL applications, I have a category implemented in the View layer that provides methods like -drawTerrain:inFrustum:cullDelegate:glContext:. First, I can cleanly separate and separately maintain code that is View related from code that is Model related. In the Direct X application, a different category defines different methods for drawing. The Model is completely re-usable. I didn't need to create new classes just to add specialized drawing capability and yet concerns remain separated. This type of capability mitigates the need for major re-factoring and limits the area of effect when re-factoring does happen.