The Inside From the Outside

A data-architect friend remarked recently that many of his developers reach into low-level database tables to extract the data they need.  Various pressures and resource constraints make this a common occurance. But it’s also a little like deciding that the right way to start your car is to first understand its electrical system, and then rewire the ignition.

One of engineering’s first duties is to separate the inside of an object from the outside, so we don’t need to know how to design a car to drive one, or design a phone to call someone, or comprehend a low-level data design to extract an analysis data set.  For this purpose engineers make interfaces: keys to start the car, touchscreens and icons to run the phone, and (hopefully) high-level views and procedures to extract useful data sets from a database.

This talk of objects and interfaces may be remniscent of object-oriented programming discussions.  In a vast literature on object-oriented programming and the languages that offer object-oriented support, we can lose sight of the target for all of this conceptual energy: the objects themselves.  Knowing what really matters about our objects can tell us a lot about the programming techniques best suited to the job.

So, what does it take to be an object?   The formalisms of theoretical physics give us two criteria: an object name, and an ID.  We need to know the kind of object we’re dealing with to draw any conclusion- whether it’s an electron, an atom, a car, an invoice, or a wave. And in physics even observationally-indistinguishable entities have an ID – we need the ability to track distinct things.  Ironically, having a unique ID is not axiomatic in data systems, and when a unique ID is missing it’s not fun, with results that can be ambiguous or simply wrong.

And what about other object attributes?  Sub-classes, methods, properties?  Normally we’ll have those, but a type name and an identifier are the core of objecthood.  The other stuff isn’t required.  Electron 1, Electron 2,  Car 1, Car 2.  Those are all good objects, even if I can’t do a whole lot with them until I add some more detail.

Practically speaking, our objects do entail more than just an ID, and engineers give us conventions – interfaces –  for working with an object. Object interfaces are not required, and we can find ourselves looking into the bowels of a data structure or a physical prototype to take some simple action.  But needing to know object details just to execute basic actions doesn’t scale well, for two reasons.  First, few users want to deal with details of a complicated thing.  We just want to use it. Second, complicated objects are changing and hopefully improving, so engineers want the freedom to make those changes without everyone having to relearn and rework their usage. So new cars still have keys, phones have touchscreens, and a car class will have methods like “color”, “mpg,” and “model” regardless of the crazy details lie within.  Interfaces are insulation – users don’t have to understand the whole world to work with something, and engineers can improve their product without impacting users.  The resulting compartimentalization allows complex systems to scale – if everyone really has to know about everything, we’re in for  a slow and bumpy development ride.

Object-oriented features like inheritance and polymorphsism are handy and powerful,  but neither is practical without object interfaces, and it is interfaces that let us do our work while understanding only part of the world.  So my vote is for the primacy of uniquely-defined objects and encapsulation when we’re thinking about object orientation. And the more definitively encapsulation separates the inside of an object from the outside, the better.

This implies that a langauge with strong object-oriented support isn’t really required to implement the practical essentials of object orientation. Programming might be easier with object-oriented support, but teams have built object-oriented systems in languages supporting functions, and little more.  Regardless, object-oriented development always seems to be a little more work.  On the whole, though,  a little object-orientation is a lot better than having to know everything about everything – I don’t know that I could figure out how to hot-wire my car.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s