I left my book and notes at work yesterday, hence the late post.

Shortcut Constructor Method

What is the external interface for creating a new object when a Constructor Method is too wordy?

Sometimes creating an object is exorbitantly wordy. The example that the author gives (in javascript) is the following:

Add methods to a lower level object that can construct your objects. Take care to only do this rarely.

This can’t be done with the example given in javascript, but the idea is to do something like the following:

Personally, I’m very wary of this idea. I see the value, but even operator overloading, which is a step HIGHER level than this, is usually viewed skeptically. I do think it’s a good idea to make shortcut methods to instantiate related objects, but that’s a far sight better than creating a method on all integers. If you do monkey-patch something like integer, it would be best if it were done dynamically, so only the code in your own project sees it.

Conversion

How do you convert an object’s format to another object’s format?

This is (at least to me) quite obvious. Some would think that they should add methods to every object to convert to other formats. So one might monkey-patch the DOM stuff to return a jquery DOM thing with the asJQDom method or something like that. Of course doing that means you’re going to end up with a ton of random conversion methods.

Convert objects by merely instantiating the second object type

This just seems so obvious I almost feel bad even writing it…

How do you set instance variables from a constructor method?

The fundamental issue here is that often validation is bypassed at construction time, for whatever reason. So one’s accessor may look something like this:

Clearly this method is just doing to much. To solve this we make special set methods that are entirely to be used during construction. So in Perl this might look like the following:

Interestingly, with Moose we happily side-step this issue, as the default constructor doesn’t go through the accessors and already sets the raw values.

Ok, so I think I may start trying to apply this stuff to JavaScript instead of Perl. I almost feel like the fact that I have Moose in Perl is cheating. I know that there is Joose in JavaScript, but I’ve yet to use that in production, and I find that I have a harder time making well factored code in JavaScript than Perl. Part of that is that the underlying libraries I use in JS (ExtJS 3) are not really well factored either, but I still struggle with overall structure.

Sadly reading is going slower than expected due to being so busy with various things in life. Oh well, just a single pattern today.

Constructor Method

How do you represent instantiation?

In addition to a vanilla constructor, add methods for common cases to instantiate typical objects. For strange cases allow the use of accessors.

Using Perl (with Moose) an example might be:

So now both of the following work:

Today I had to spend time taking care of passport stuff for my upcoming honeymoon, so I only got to read a handful of pages. I’ll post my notes nonetheless.

Methods are more important that state because, correctly factored, methods paper over any changes in state over time. Most of us who took OO classes in college had this hammered into our brains

Methods should be written to get something done, but should also be written to communicate with the reader. Method names like “task_1″, “task_2″, etc are completely useless for a regular person, and should be named as to what they actually do.

Small methods are expensive in that they cost more CPU cycles and typically cause the novice trouble in following the structure of a program. On the other hand, more methods means more human readable names, easier maintenance (pinpointing changes,) and method overrideability is much more feasible with small methods.

Composed Method

How do you split your program into methods?

As already mentioned, large methods are faster and easier for the reader to follow, but small methods with good names work well in the long run. A seasoned programmer is able to see a method and assume what it does without needing to read the code for it. On top of that, small methods with good names allow you to communicate the structure of your code to the reader. Also, small methods are a must for inheritance.

Split your program into methods that do a single identifiable task.

A Perl example might be something like:

The Composed Method patter can be used in a top down fashion, that is, write your higher level methods in an almost pseudo-code fashion, and then fill in the details of the lower level methods as you work. You may also opt to use the bottom up approach of writing a larger method and splitting it into smaller methods as you notice repetition or other reusable structures. Or lastly (and I think the most new idea to me) you can use this to find holes in your API. So if an object is calling more than one method on another object, the second object probably needs to implement a method that will encapsulate the multiple calls.