May 30, 2003
What is an object?

A post over at steered me towards this - Building user interfaces for object-oriented systems.

It has some interesting, if perhaps somewhat controversial, things to say on the nature of object orientation.

You may have read in a book somewhere that an object is a data structure of some sort combined with a set of functions, called methods, that manipulate that data structure. Balderdash! Poppycock! First and foremost, an object is a collection of capabilities. Very true, this. The important thing about an object is what is does, not what it has. The latter is an implementation matter.

Classes are irrelevant -- they're just a convenience provided for the compiler. Also true. This was pointed out to me while looking at JavaScript recently. Its rather, uh, idiosyncratic OO model does away with 'classes' as such. Instead, you just define a construction function, and add methods to its prototype. Look, Ma, no classes. (I don't really like this approach much - it makes subclassing rather clumsy if nothing else. But it does work after a fashion.)

All data is private. Period. (This rule applies to all implementation details, not just the data.) get and set functions are evil. (They're just elaborate ways to make the data public.) I like Python's approach here. No data is really private (see The principle of least privilege for why), but you can intercept any references to this data if you want. So, you just refer to object.attribute, and it's the object's business whether that just accesses the data attribute or calls a method. No need for get and set methods here.

All objects must provide their own UI. What? Is he serious? The presentation object should always be separate from the business object! Some business objects don't need any presentation layer, and some may need several. (The persistence layer should also be separate.)

Posted to Software development by Simon Brunning at May 30, 2003 10:43 AM
Post a comment

Email Address:



Remember info?