Lazy Object Orientation

Touched off by a post by Chris Hanson:

Collections are quite widely used in a lot of the code I see posted to the Cocoa-dev mailing list and elsewhere. Unfortunately, many times they’re not used to represent collections of objects but rather to represent objects themselves.

If I may speculate a little about why this is, it’s that perhaps a lot of programmers are coming from the Ruby/Python/PHP/JavaScript web development world, in which an object is usually an XML document or a database row, and interacting with your data model is defined in terms of xmldocument.getElementsByTagName() or db_row[’colname’]. It’s lazy object oriented programming, a style in which objects are constantly instantiated and called, but only either a) language or framework objects or b) utility objects representing really base primitives like a database or the filesystem.

It’s not that there aren’t real O/R mapping toolkits out there for these technologies (RoR’s ActiveRecord comes to mind, and, well, I haven’t seen any for JavaScript over XMLHttpRequest yet), it’s just that everything in the web developer world seems to be done in the name of fast, fast, fast. Your competitor(s) are copying your features relentlessly and the drive to innovate trumps pretty much everything else. “Modeling” is in some cases viewed as a sugar coating over the bare metal of the AJAX response or the database row, one which will also need to be maintained in a rapidly-changing environment. And everything’s gotta be serialized into some form for transmission to a client using an unknown technology (probably XML), so what’s the point of having classes in between?

So, I don’t fault the programmers who code like this — this is perhaps the world with which they’re the most familiar. And, outside Mac OS X, the tools just aren’t as good for writing well-factored code both easily and quickly. And once a habit is learned, well…

About this entry

You’re currently reading “ Lazy Object Orientation ,” an entry on stuffonfire.com

Published:: 12.24.06 / 4am

Category:: Programming

Nikita Zhuk 12.24.06 / 5am

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.

daver 12.24.06 / 5am

I’m aware of the Java-based tools. Notice that I never mentioned Java in my original post.

Scott Stevenson 12.24.06 / 8am

For what it’s worth, I don’t think blasting away basic software practices saves you time overall. It may temporarily give you the illusion of saving time, but as soon as you need to change something, a bit of abstraction can really help.

ndimiduk 1.4.07 / 10am

Refactoring tools? What’s so hard about regex search-and-replace? Sure, use your IDE-d’jour for making tedious things easy, but use a ~~real~~ programmable editor for your surgical coding needs.

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.

Carl 1.5.07 / 8am

ndimiduk I think you’re overlooking the benefit of the refactoring tools.

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

drew 2.23.07 / 10am

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.

guanhua 4.5.07 / 9am

On personal opinion, I find this very helpful.
Guys, I have also posted some more relevant info further on this, not sure if you find it useful: http://www.bidmaxhost.com/forum/

VirtualRabbit 4.11.07 / 9am

I like this so-called “Lazy Object Orientation” - I find myself using it more and more in Cocoa and Java. I find it offers a lot of advantages over proper structures. You get serialization and easy debugging output (NSLog(@”Object: %@”, ob) for free, it’s easy for other processes to examine your objects, and they are useful for initialization structures or returning tubles.

Joe 2.7.08 / 2pm

This so called “Lazy Object Orientation” is correct programming practice. The programmers who make a class for every object type in their program, even when said objecti s nothing more than a container for some data– are the mediocre programmers. It seems that somewhere in their development, they became so in love wiht subclassing that everything is a subclass.

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.

Sean Maher 9.23.08 / 4pm

Guilty as charged, right down to the Javascript/Actionscript background. When I started my first cocoa app I did the same thing - just fired up some dictionaries to hold my data. Development was fast and easy… until I wanted to add some methods to access the data (can’t!) and until the lack of type checking started to byte me in the ass. Live and learn! I bit the bullet and changed to real classes instead of dictionaries, and after two days of refactoring, went forth to sin no more.

stuffonfire.com

Lazy Object Orientation

About this entry

10 Comments

Have your say

About

Recently

Categories

Comments