Objects Can't Ask to Be Born

06/01/09

I think because Rails makes application construction so easy, even folks with real CS degrees fail to get serious about object modeling. Maybe object modeling is too broad a term for what I am talking about. Even when working with something like jQuery which can go functional, there is a need to separate out concerns. I think of this work as dismantling programming codependence.

I tend to do lots of my architecting on a logic instinct level. This week someone came along and told me that I had setup a ‘publisher/subscriber’ system. So, I looked at what I had done and it seemed really obvious that it was just that. At the time, I wasn’t looking through my bevy of design patterns. I just wanted to find a way to make my data available in a number of satellite applications.

So, I was interesting this week to finally fully think out object creation and destruction.

When an object is created in Ruby the class has to do that work because 1) instances shouldn’t be responsible for creating other non-clone instance, and 2) an instance may not yet exist to do that co-dependent work. Of course Matz, standing on the shoulders of other object-oriented giants, has already taken that into consideration for us.

When dealing with jQuery and the possibility of packaging up lots of related functionality in non-established object ways, our app ran into just this problem: instances were made responsible for creating more instances. That works if you can always guarantee the presence of an object. It isn’t the right way to do it though. Because, objects can’t ask to be born. They just aren’t there yet. But the parent organizer, which in Ruby is the class, and in jQuery might be a set of parent functions, can spawn an objectish thing. It is really obvious when you think about it, but I hadn’t thought of it.

On the other hand, object instances are perfectly capable of destroying themselves, just like people can commit suicide.