Erik Buck

Member since: Feb 15th, 2007

Erik Buck's Latest Comments

Blog Activity

Blog	# of Comments
Download Squad	2 Comments

Recent Comments:

Dev Chair : My love-hate relationship with Apple development (Download Squad)

Feb 16th 2007 12:30AM 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.

Dev Chair : My love-hate relationship with Apple development (Download Squad)

Feb 15th 2007 9:15PM As one of the authors of "Cocoa Programming" ISBN: 0672322307, I may have a different view on this subject.

I don't think Apple is trying to discourage new developers by setting a bar high. In contrast, by providing professional (and in some cases best of breed) development tools free with the operating system, Apple is only encouraging adoption.

I too am a professional Windows programmer, and I think the available resources for Apple far exceeded what is available from MSDN. Try developer.apple.com sometime. You might also notice that the complete source code for the TextEdit application (along with others) is already on your hard disk if you have installed developer tools/examples.

In my experience, re-factoring tools are much less needed with Cocoa applications than with many other types of development, but I concede that re-factoring is a weak spot with xCode.

Finally, Cocoa is the successor to Openstep, in in many respects, Openstep was/is the only successful write once run anywhere framework. http://en.wikipedia.org/wiki/OPENSTEP It is only Apple's licensing and not technology that keeps Cocoa applications off Windows.