| « Why Great Development Tools Don’t Seem To Be Written In PHP | Announcing Blueprint DC » |
As Benjamin Franklin once famously said, “the only two things that are certain in life are death and taxes.” His point, while political, has a good perspective on one of life’s ever-persistent truths: the fact that governments exist in every country, and, largely, they have some of the same benefits and drawbacks everywhere.
However, the ubiquity of governments around the world also gives us a unique opportunity to learn some lessons from them as developers, particularly about principles of object oriented programming. Governments serve as perfet object lessons (pun intended), demonstrating some of the good, the bad, and the ugly object-oriented practices we see.
First a warning: because the purpose of this post (and this blog) is not to discuss politics, comments about politics won’t be approved. Each comment will be moderated.
In reality, government serves as one big object-oriented application in many ways. Government excels in the areas of abstraction, encapsulation, the implementation of dumb objects, decoupling and giving one class a single responsibility. Let’s examine each of these as programming practices and see what we can learn.
Abstraction
Governments are really good at abstraction – almost too good, sometimes. Abstraction is the principle that you can take complexity and break it down internally to ensure that the appropriate object, with the appropriate inheritance and components, does the appropriate task.
Governments do this largely by creating a bureaucracy. Programmers do this by creating parent and sub- classes that have specific responsibilities. Object-oriented applications are, by default, bureaucratic – when abstraction comes into play, you give objects specific responsibilities and abstract out the peripheral things that might otherwise be included when doing functional programming. However, it works well in object-oriented programming because objects follow specific rules absolutely – meaning your “bureaucracy” doesn’t make mistakes along the way.
Encapsulation
This is one area of object-oriented programming that we don’t discuss often enough (I’m not sure I’ve ever mentioned it). Encapsulation is the practice of concealing the inner-workings of an object from the objects that pass messages to it.
Governments do this by creating front-line and back-line workers. Take, for example, the courts: you have clerks, judges, and others who deal with the “customers” – criminals, lawyers, plantiffs, etc. But each court system has hundreds of other workers who file, copy, collate, prepare dockets, update websites, and do other functions that are behind the scenes but are crucial to the operation of the object (the court).
As developers, we can do this by shielding internal functions with the protected and private keywords (in PHP, anyway). These keywords make it impossible for those outside our objects to mess with the inner workings, but still allow those innerworkings to proceed. We have our “front line” (our public API) and our “back line” (our protected methods) which do other crucial, internal work.
Dumb Objects
Lots and lots of people complain about how each department they work with independently requires verification of the same documents before they can proceed. For example, in applying for the proper permits for my business, I had to submit proof that my LLC was established and in good standing before I could get a Home Occupancy Permit, and I’ll have to show the Home Occupancy Permit paperwork before I can get a business license. And this is the same department of Washington’s government – the Department of Consumer and Regulatory Affairs. You’d think that they could work together and share the same database, right?
Not so fast! The government has done something that more programmers ought to do: it’s created “dumb objects.” This is not to say that the workers who do the work are dumb; instead, the departments themselves are dependent on you giving them (dependency injection) the proper documentation.
People have debated for a long time on whether or not this is appropriate behavior for government, but it the undisputed perfect behavior for software applications. By requiring that objects be provided (injected) into other objects, you create objects that don’t really care what else is going on in the application so long as their dependencies are met.
This is a crucial component of software development. If your objects are “too smart” it makes it hard to refactor later on, and means that you have to be just as smart as your objects – sometimes a tough task if the object is complex and does lots of complex things. For example, can you imagine building an Escalator object and having to understand how all the parts work internally before you can modify the direction of the escalator? That would be silly; and so it is silly to have objects that are too smart.
Decoupling
In a perfect world, you would be able to take a government bureau out of where it is, and drop it into another department and have it operate perfectly. In a perfect world you’d also be able to take any class out of a library, drop it into another library, and implement the class without trouble.
But we don’t live in a perfect world, do we?
As developers, we like to tightly couple our applications. We like to make them depend too heavily on one another, and rely on each other for things. Governments try and avoid this, hoping to make work easier to perform by not having things as complex. By decoupling one group from another, they allow for work to move forward without necessarily utilizing another group.
We should do this as best we can, too. It’s impossible to decouple our objects from each other all the time (for example, libraries are necesarilly coupled). However, it is the creation of libraries that allow for us to decouple our objects better: libraries are intended to be used elsewhere, and so we necessarily design them that way.
One Class, One Responsibility
When applying for my LLC, I went to a particular desk. When I had to get a home occupancy permit, I had to go to the permits desk. When I go back for my business license, I’ll have to go to a third desk. People tend to complain about this type of thing where government is concerned. “Why can’t I just go to one place and get it all done?” they ask.
But in software development, we should drool over the concept of “one object, one responsibility,” which is exactly what I just described. The Corporations desk does one thing: register corporations. The permits desk does one thing: decide permits. All kinds of permits, yes, but they decide permits. That’s it. They don’t issue licenses, and they don’t register corporations.
Developers like to have objects do far too much. They read the file AND set the configuration AND handle the display. That’s two actions too many and, depending on how your application is designed, it might be wise to abstract the application even further.
Summary
Governments tend to do some things that frustrate consumers of government services, but should delight the inner programmer in us for their object-oriented principles. In truth, most of these could be applied to big business or large organizations as well; but we should apply them to our programming instead.
Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP
Posted on 12/2/2009 at 1:00 am
Andre wrote at 12/3/2009 1:04 pm:
Nice article, I like these kind of posts. It would be nice if you accompanied real sample code with each example. Even naming the classes with government names would go a long way in explaining the points to newer programmers.
| « Why Great Development Tools Don’t Seem To Be Written In PHP | Announcing Blueprint DC » |