If off the shelf classes have the functionality that is needed, then subclassing them is very poor programming practice– it lets you guys think you’re brilliant but gets in the way of understandability.

This is even more the case in objective-c where you can add methods without subclassing.

The point remains, however, that developing for the desktop platform is fundamentally different than developing for a web platform and thus different paradigms tend to surface.

The only fundamental difference between the two is the stateless nature of the web, and even that can be cobbled over to some extent. (APS.NET tried to do it with WebForms, and while I generally despise the implementation, some of the ideas aren’t behind it aren’t so bad.)

The truth is, there are poor undisciplined web developers just as there are undisciplined desktop application developers. If you take a solid OO programmer from one environment from one environment and drop them in the other, they will probably do just fine(*). If you take a mediocre programmer from one environment and drop them in the other, then, your results are going to be, well, mediocre…

(*) Although I have found that web programmers coming from a Java / C# / etc. background do seem to spend an awful lot of time trying to make inheritance in JavaScript look like they think it should.

Imagine you want to rename a method (from ‘name’ to ‘description’) in a project with, I don’t know, let’s say 2000 classes. Your process would be to rename the method and then (recursively) grep or search and replace the old for the new … with many compile iterations each time to check where there are still some you missed.

However, what would you do if there are 10 or 15 classes with the same method name? Now you’re in trouble because you’re searching and replacing what?

[obj name] for [obj description] … ahh, but that’s going to pick up the other 15 classes that also have a “name” method.

Okay, so you change your search/replace to:

[objectNameThatIGenerallyUseForThisClass name] for [objectNameThatIGenerallyUseForThisClass description] … but you’ve forgotten that there were a number of places where you had to use a different name … oops!

It’s not until you’ve tried to do this in a large project that you realise that it’s not the answer! Doing something like this can take days!

So you use the other approach, rename the method and then write a new method, with the old name, that delegates to the newly renamed method. Cool! Now you’ve got two methods for the price of one! ;o)

You then spend the rest of the project’s life tracking down callers that are still using the old method.

Refactoring tools allow you to do simple things like rename a method by, well, just renaming it. It’s able to rename the method on all callers for you at the same time.

Now, personally I wouldn’t trust that refactor to a human!

Cheers,
-Carl

There’s nothing specifically wrong with using container objects to hold your data. The trouble comes up when you need to grow your project beyond the basic data types. Object Orientation starts to shine when you can hide you NSArray of Goobers from your GooberConsumer. If the array is hidden by an object and accessor methods, you can later change from a NSArray to your shinny new SuperCoolGooberCollection and the only thing GooberConsumer will notice is a net increase in speed (well, maybe a decrease in speed if it’s not as super-cool as you had hoped — NSArray is rather super-cool).

The point remains, however, that developing for the desktop platform is fundamentally different than developing for a web platform and thus different paradigms tend to surface. Oh, and IDEs are a tool, just like emacs, vi, and sed, and awk; don’t treat them like crutches. There’s no way I’d trust an IDE to “refactor” my personal project, any more than my employer would trust an IDE “refactor” any of our code. Code is poetry, you JUST DON’T DO THAT to your lovingly-pruned bonsai.

And, outside Mac OS X, the tools just aren’t as good for writing well-factored code both easily and quickly.

Actually, weak tools are the biggest reason for me to (sometimes) use lazy object orientation in Cocoa/Objective-C code. Currently XCode doesn’t offer any tools for refactoring - even renaming an ivar or a class is manual and error-prone job. That’s why there’s always a bit of hesitation before creating a new class in XCode - you know that managing it later will be a bigger burden than it needs to be. This is especially the case when the problem domain of your application cannot be completely specified in advance and you know that you will need to change some parts of your data model later. Although XCode 3.0 will offer some degree of refactoring support it’ll be still light years behind such Java IDEs like IntelliJ IDEA or Eclipse.