By BoLOBOOLNE payday loans

The Magic Wand of Encapsulation

I have a hat in my office.  It’s a magic hat.  You can ask it any question about software engineering, coding, or object-oriented design, and it will give you the answer.  Just reach in and pull out a slip of paper and be amazed at the wisdom of the hat.  Follow its advice and you’ll never go wrong.

Every slip of paper says the same thing: "Encapsulate it."

Back in the 1980’s we all knew that global variables (or common blocks in Fortran) were evil.  They led to subtle, hard-to-find bugs.  We all know the kind — you call a function and don’t realize that it has some subtle side-effect outside of what you want it to do, and that breaks something else.  The irony is that you don’t need global variables to get this kind of bug.  (But they sure do make it easy.)  This is a totally common description for a hard to find bug.  A great way to avoid this is to encapsulate your code so it doesn’t do anything outside of the playground it’s supposed to be working in.  The only access is through well-defined interfaces.

My first glimpse at this came with Borland’s Turbo Pascal which
offered to make sets of variables only visible to certain blocks of
code.  Object Oriented Programming (OOP) takes this the next step with polymorphism and the still-unrealized promise of code re-use.  But I’d argue the true value of OOP is the ability to organize your code into chunks that have nothing to do with each other execpt through well-defined interfaces.

Some languages like .net provide mechanisms to enforce encapsulation
of entire libraries from each other — this assembly cannot call
anything in this assembly.  DLLs can only call certain DLLs.  Good java programmers take careful note of which packages include which other packages, but AFAIK the language doesn’t offer much in the way of tools for enforcing this.  A friend of mine spends his entire job
trying to enforce this kind of library-level encapsulation on the Windows codebase.
(Keep up the good work, Mark, please.)  The trend towards service-oriented
architectures (SOA) can be seed as a way to formalize this kind of higher-level encapsulation.  If the procedure you’re calling is on a different machine, you’ve got a high degree of confidence in its encapsulation.

Another key benefit of encapsulation is that when it comes time to change something — say swap something out for a replacement that does it better.  If the new code follows the same interface, all the other code that works around it should keep working unchanged.  Herein lies the true wisdom of the magic hat: if you’re ever not sure how to write a piece of code, take whatever it is you’re not sure about, and encapsulate it so that you can change that aspect of it later.  It might seem like a pain in the ass to decouple these things, but the fact that you’re not sure about which way to do it probably means it’s a good place to put an interface layer.  Now it’s up to you to decide if this interface is just a class-boundary, or something higher-level like a package/DLL/assembly boundary or even has to go through an RPC/SOAP/service layer.  But you’ll rarely go wrong with extra encapsulation.

Comments are closed.