Object-Oriented Government (analogy)

Object-Orientation and the structure of a “normal” Government

Fabulous analogy created by Brandon Savage links the main OO concepts to the tasks, responsibilities and departments of a government. He believes programmers should learn with it and use these concepts. I think he is right in many things he said and that it makes a great blog post. Here is a short summary of what I think his article says and if you want more details, go see Five (Good) Lessons The Government Teaches Us About Object-Oriented Programming.

He lists 5 intersections between programming concepts (or principles) and Government's structure:

Abstraction
By creating many objects to do a task that once was the job of only one, is called abstraction. This makes each object more simple and able to do only one thing. Government abstraction? Bureaucracy.

Encapsulation
Protect and private functions, inside a class, 'encapsulates' its action. That means objects outside the current instantiated one won't have access to it. Government encapsulation? Among other possible examples, front-line and back-line workers. One deals with the public and the other doesn't. (Good try Brandon, this analogy kind of worked :.)

“Dumb Objects”
Objects that are 'too smart' (love that) demand more time and effort to understand and alter them. Instead of having this complex chain of variables and objects, why not make these objects less clever? The idea here is to test the parameters that are being injected into it and use it. This prevents errors and makes the later debugging much easier. Government 'Dumb' Objects? Itself! Well, have you ever had to present the same document to different departments when all you want is to see a doctor, register a business or something like that? Well, the departments could have an integrated database, but like this they are easier to manage.

Decoupling (or de-normalization)
A variation of the 'dumb' objects. It consists of the ability to move an object, or class, form one library to another, simplifying, once again, the management and debug. Governments like that and the less reliable a department is on a particular person the more flexible the system is. I personally think this happens because of lack of training budget. The same works for a developer..

Many classes working on one single job
Exactly like going to different departments and buildings to get one single task done, many systems have many objects, with different activities, working on the same action-flow. People complain about it when it concerns to governments, but what they don't realise is that what they are doing isn't one single task, it is many that looks like one.