Structure and Interpretation of Computer Programmers

I make it easier and faster for you to write high-quality software.

Saturday, April 25, 2009

On dynamic vs. static polymorphism

An interesting juxtaposition in the ACCU 2009 schedule put my talk on “adopting MVC in Objective-C and Cocoa” next to Peter Sommerlad’s talk on “Design patterns with modern C++”. So the subject matter in each case was fairly similar, but then the solutions we came up with were entirely different.

One key factor was that Peter’s solutions try to push all of the “smarts” of a design pattern into the compiler, using templates and metaprogramming to separate implementations from interfaces. On the other hand, my solutions use duck typing and dynamic method resolution to push all of the complexity into the runtime. Both solutions work, of course. It’s also fairly obvious that they’re both chosen based on the limitations and capabilities of the language we were each using. Nonetheless, it was interesting that we both had justifications for our chosen (and thus One True) approach.

In the Stroustroup corner, the justification is this: by making the compiler resolve all of the decisions, any problems in the code are resolved before it ever gets run, let alone before it gets into the hands of a user. Whereas the Cox defence argues that my time as a programmer is too expensive to spend sitting around waiting for g++ to generate metaprogramming code, so replace the compilation with comparitively cheap lookups at runtime – which also allows for classes that couldn’t have possibly existed at compiletime, such as those added by the Python or Perl bridge.

This provided concrete evidence of a position that I’ve argued before – namely that Design Patterns are language-dependent. We both implemented Template Method. Peter’s implementation involved a templatized abstract class which took a concrete subclass in the realisation (i.e. as the parameter in the <T>). My implementation is the usual Cocoa delegate pattern – the “abstract” (or more correctly undecorated) class takes any old id as the delegate, then tests whether it implements the delegation sequence points at runtime. Both implement the pattern, and that’s about where the similiarities end.

posted by Graham Lee at 19:44  

Monday, February 23, 2009

Cocoa: Model, View, Chuvmey

Chuvmey is a Klingon word meaning “leftovers” – it was the only way I could think of to keep the MVC abbreviation while impressing upon you, my gentle reader, the idea that what is often considered the Controller layer actually becomes a “Stuff” layer. Before explaining this idea, I’ll point out that my thought processes were set in motion by listening to the latest Mac Developer Roundtable (iTunes link) podcast on code re-use.

My thesis is that the View layer contains Controller-ey stuff, and so does the Model layer, so the bit in between becomes full of multiple things; the traditional OpenStep-style “glue” or “shuttle” code which is what the NeXT documentation meant by Controller, dynamic aspects of the model which could be part of the Model layer, view customisation which could really be part of the View layer, and anything which either doesn’t or we don’t notice could fit elsewhere. Let me explain.

The traditional source for the MVC paradigm is Smalltalk, and indeed How to use Model-View-Controller is a somewhat legendary paper in the use of MVC in the Smalltalk environment. What we notice here is that the Controller is defined as:

The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate.

We can throw this view out straight away when talking about Cocoa, as keyboard and mouse events are handled by NSResponder, which is the superclass of NSView. That’s right, the Smalltalk Controller and View are really wrapped together in the AppKit, both being part of the View. Many NSView subclasses handle events in some reasonable manner, allowing delegates to decorate this at key points in the interaction; some of the handlers are fairly complex like NSText. Often those decorators are written as Controller code (though not always; the Core Animation -animator proxies are really controller decorators, but all of the custom animations are implemented in NSView subclasses). Then there’s the target-action mechanism for triggering events; those events typically exist in the Controller. But should they?

Going back to that Smalltalk paper, let’s look at the Model:

The model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller).

If the behaviour – i.e. the use cases – are implemented in the Model, well where does that leave the Controller? Incidentally, I agree with and try to use this behavior-and-data definition of the Model, unlike paradigms such as Presentation-Abstraction-Control where the Abstraction layer really only deals with entities, with the dynamic behaviour being in services encapsulated in the Control layer. All of the user interaction is in the View, and all of the user workflow is in the Model. So what’s left?

There are basically two things left for our application to do, but they’re both implementations of the same pattern – Adaptor. On the one hand, there’s preparing the Model objects to be suitable for presentation by the View. In Cocoa Bindings, Apple even use the class names – NSObjectController and so on – as a hint as to which layer this belongs in. I include in this “presentation adaptor” part of the Controller all those traditional data preparation schemes such as UITableView data sources. The other is adapting the actions etc. of the View onto the Model – i.e. isolating the Model from the AppKit, UIKit, WebObjects or whatever environment it happens to be running in. Even if you’re only writing Mac applications, that can be a useful isolation; let’s say I’m writing a Recipe application (for whatever reason – I’m not, BTW, for any managers who read this drivel). Views such as NSButton or NSTextField are suitable for any old Cocoa application, and Models such as GLRecipe are suitable for any old Recipe application. But as soon as they need to know about each other, the classes are restricted to the intersection of that set – Cocoa Recipe applications. The question of whether I write a WebObjects Recipes app in the future depends on business drivers, so I could presumably come up with some likelihood that I’m going to need to cross that bridge (actually, the bridge has been deprecated, chortle). But other environments for the Model to exist in don’t need to be new products – the unit test framework counts. And isn’t AppleScript really a View which drives the Model through some form of Adaptor? What about Automator…?

So let me finish by re-capping on what I think the Controller layer is. It’s definitely an adaptor between Views and Models. But depending on who you ask and what software you’re looking at, it could also be a decorator for some custom view behaviour, and maybe a service for managing the dynamic state of some model entities. To what extent that matters depends on whether it gets in the way of effectively writing the software you need to write.

posted by Graham Lee at 22:45  

Saturday, October 4, 2008

Properties about a year on

Leopard has now been out for nearly a year, which means that (publicly) we’ve had Objective-C 2.0 for the same amount of time. At the release many developers were champing at the bit to talk about the new language capabilities[], including properties. There were arguments on both sides of the divide, and even a little bit of discussion. But now that we’ve been using these things for a while, and because I’m bored awake grouchy vocal opinionated, let’s have a look back at what they’ve given us.

There is a broken abstraction in traditional Objective-C, which is the accessor-method-as-property-declaration. Essentially an object can give you two things; work (i.e. it can do stuff) and state information (i.e. it can say stuff about itself and let you change it). In traditional object-oriented languages, because ‘saying’ and ‘changing’ are verbs which can be ‘done’, the two have both been expressed using the same method (heh) as the expression of work. This is not the case in much object-oriented design, for instance in UML a class always has separate “attributes” and “operations”.

Properties fix up this abstraction by giving us orthogonal ways to express the two concepts. Work is done in methods; state is got/changed in properties. Now it may be that the state information is actually backed by a method (although it may bang on the ivar directly; more below), but we don’t need to know that any more than we need to know in the interface that a property is synthesized or dynamic. All we do need to know is that it is there for us to use, and has certain attributes such as being read-only.

The “on more below” bit is that discussions of KVC-like mechanisms – such as KVC :-) – often involve someone pointing out that they break encapsulation, because it’s possible to access an @private ivar with no accessors by retrieving it by key. That’s really thinking about the design of a class in terms of the way it’s executed rather than its interface contract with the developer, because the @private ought to tell the developer not to touch that particular ivar. Properties neither help nor hinder breakage from the execution side, but from the design side they do provide a stronger distinction between “properties I’m telling you about in the interface” and “things you shouldn’t touch”. Now we can all get back to using the class’s interface to observe how to use it, and that C struct bit at the top to observe how to extend it, as nature intended. It’s both a blessing and a curse that Objective-C allows things to appear in source files which don’t make it into the executable code, but that doesn’t stop such information being useful to the developer in the same way that code comments can be read but not executed.

One of the popular complaints about ObjC properties is the syntax for referring to them in methods (OK, or indeed in functions), where it is argued that myObject.someProperty = 4; doesn’t readily tell you whether myObject is an ObjC object, a C struct or a C union. That seems to be at worst a straw man argument to me, and at best a hypothetical issue; in well-designed software it will be rare to mix code at various levels of abstraction except in limited circumstances such as adapter classes. Besides, if the code has been written such that it can be inspected or reviewed (i.e. to some agreed style and standard) and the reviewer is paying attention then it will be easy to distinguish use of the various types. At some conceptual level the C . and Objective-C . operator are doing the same thing anyway; they’re both saying “this attribute of that thing”.

[]The fact that I have stopped using the word ‘feature’ in many contexts is an entire blog post and a few therapy sessions in itself.

posted by Graham Lee at 06:20  

Sunday, September 28, 2008

MacDev 2009!

It’s a long way off, but now is a good time to start thinking about the MacDev ’09 conference, organised by the inimitable Scotty of the Mac Developer Network. This looks like being Europe’s closest answer to WWDC, but without all those annoying “we call this Interface Builder, and we call this Xcode” sessions. Oh, and a certain Sophist Mac engineer software will be talking about building a secure Cocoa application.

posted by Graham Lee at 20:27  

Monday, September 1, 2008

A better bit o’ twitter than the bitter twitter Tommy Titter bought

Just because everyone these days writes a Twitter client:

This was actually a quick hack project to make up for the fact that I missed CocoaHeads tonight (due to a combination of an uninteresting phone call, and a decision to recover from the phone call by using the rest of my petrol tank). Really just an excuse to play with some APIs (the tweets are grabbed by the controller using NSURLConnection, then some NSXML/XPath extracts the useful information (or not, it is Twitter after all) and puts it into the model), there are many things which need to happen before this is at all a useful Twitter client; the ability to write back, nicer formatting are just the starters. Shiny Core Animation twitting ought to happen.

Still, not bad for two hours I think.

posted by Graham Lee at 22:26  

Saturday, December 8, 2007

Objective-C Design Patterns

Certain events at work have turned me into a bit of a design patterns geek of late, and as such I stumbled across this DDJ article from 1997 (the title of this post is the link). According to del.icio.us not many other people have stumbled across it, but it’s a great article. The code listing links seem to 404 even though the listings are at the bottom of page 1 of the article.

Something very important can be learned from this article, which is at best covered tangentially in the GoF book: Design patterns are not language-independent. Calling the C++ and Objective-C ways of writing code "pattern idioms" ignores the point that actually, the code you come up with is more important than the design (customers don’t typically want to pay the same cash for your UML diagrams that they do for your executables), and gasp different languages require different code! Different patterns can be used in ObjC and Smalltalk than in C++, and different patterns again in object-oriented Perl. Different patterns will be appropriate for working with Foundation than with the NeXTSTEP (pre 4.0) foundation kit or with ICPak101. Designing your solution independent of the language and framework you’re going to use will get you a solution, but will not necessarily produce the easiest solution to maintain, the most efficient solution or one that makes any sense to an expert in the realm of that language and framework.

posted by Graham Lee at 20:32  

Powered by WordPress