In Praise Of: Encapsulation
Programmers learning about object orientation soon discover the three tenets of object orientation: polymorphism, inheritance and encapsulation. Discovering the power of inheritance is often a heady experience and newbie OO programmers discover inheritance in every relationship--just as first year medical students discover a variety of terminal ailments in every organ. What's required is a bit of perspective.
What is inheritance? It's a way of modeling into software a relationship between two clases (or CFCs for our purposes) in which one CFC is a specialized type of another CFC. For example, a SportsCar is a specialized type of Car. A Car might be modeled as a specialized type of Vehicle. A Vehicle might be modeled as a specialized type of Machine.
In CFCs, the mechanism to provide for inheritance is very simple: in the <cfcomponent> tag, set the extend's attribute's value to the base class. For SportsCar, this would look like this:
<cfcomponent hint="SportsCar" extends="Car">
Computers are incorporated in modern ice cream vending machines to enhance their functionality. Ice Cream Vending machines are manufactured by many companies. Your competition will try to overcome all requests for high-tech ice cream vending machines and credit card acceptors
|
|
Now, any object created as a SportsCar will inherit the methods and properties of the base class, Car. If Car already has a method called "start", for example, there's no need to write a "start" method for SportsCar; it's already available.
Cool stuff. But dangerous. Inheritance chains (or trees) can be very fragile. The longer the chain (the more attenuated the inheritance becomes), the greater is the danger. While the subclass always knows what it is extending (SportsCar knows that it extends Car), the base class has no knowledge of who is extending it and changes made to the base class can cause trouble for subclasses.
As this example may indicate, there are many pitfalls awaiting the inexperienced OO designer. Luckily, one simple principle will help us avoid many of these dangers. That principle is encapsulation. Jim Rumbaugh, one of the early OO theorists defines encapsulation like this: "Encapsulation consists of separating the external aspects of an object which are accessible to other objects, from the internal implementation details of the object, which are hidden from other objects."
If that still seems difficult to grasp, let me provide an example of encapsulation: look at the wall socket your computer is plugged into. It provides a well-encapsulated means of gaining electrical power. As such, it offers a way of interacting with it (the wall socket), but hides its internals--things like the type of wire used to transmit the electricity, the type of energy used to produce the electricity, and so forth.
Encapsulation answers the all-important "what" question--as in "What does this component do?" By contrast, implementation details answer a "how" question--as in "How does this component do what it does?" Still an interesting question, but unless you're directly involved in writing the code for this, it's a question that can remain unanswered--so long as you can count on a stable interface to the object in question. In fact, my own assessment of importance of the three OO tenets referred to earlier is this:
- encapsulation
- polymorphism
- inheritance
But what if you don't write OO code? Encapsulation is no less important for procedural programmers, though it's often more difficult to achieve, since procedural languages lack some of the tools for encapsulation that their OO counterparts have. But procedural programmers still have resources available. With ColdFusion MX, we have such things as custom tags, user-defined functions, and ColdFusion components (CFCs).
More than tools, though, successful encapsulation relies on a mindset that values simplicity. I've written before about what I consider to be the greatest single threat to maintainable software: complexity. Encapsulation is a way to tame the wild tangle of code and logic that complexity produces.
Looked at in another way, the problem of inheritance trees lies in this oft-repeated statement: inheritance breaks encapsulation. By allowing one component access to the internals of another, we sacrifice some encapsulation. While this is sometimes a worthwhile sacrifice, we need to be very careful lest we become enamored with it and find that the wild beast of complexity has been unleashed on our code.
ColdFusion programmers have two powerful frameworks for writing code that embody encapsulation. For procedural programmers, the recently-released Fusebox 4 is a powerful, mature framework that can help enforce encapsulation. For OO programmers--or programmers who want to become OO programmers--Mach-II is a new, robust framework that incorporates some of the best thinking in computer science. If you haven't looked at Fusebox and/or Mach-II recently, check them out:
Fusebox 4: www.fusebox.org
Mach-II: www.mach-ii.com
Upcoming Hal Helms training
Java for ColdFusion Programmers, Oct 6-10, Atlanta: http://halhelms.com/index.cfm?fuseaction=training.javaDetails
FastTrack to Fusebox 4, Sep 29 - Oct 1, Atlanta: http://halhelms.com/index.cfm?fuseaction=training.ftfbdetails
Mach-II: Building OO Applications with ColdFusion MX, Oct 15-17, Washington, DC: http://halhelms.com/index.cfm?fuseaction=training.machdetails
Project Success: Working with FLiP: http://halhelms.com/index.cfm?fuseaction=training.flipDetails
|
