Published: Monday, September 18, 2000
Using Object-Orientation in ASP.NET : Encapsulation
By Ian Stallings
Encapsulation (Information Hiding). A principle, used when developing an overall program structure, that each component of a program should encapsulate or hide a single design decision... The interface to each module is defined in such a way as to reveal as little as possible about its inner workings. [Oxford, 1986]
- Peter Coad and Edward Yourdon. Object-Oriented Analysis, 2nd ed. Englewood Cliffs, NJ. Prentice Hall
This article attempts to explain the concept of Encapsulation in a OO environment. It assumes you have some
understanding of OO (if you've not yet read my earlier article, Using Object-Orientation in ASP.NET : Overview,
you might wish to do so before continuing with this article). For more information on OO you can also visit the
OO FAQ at http://www.cyberdyne-object-sys.com/oofaq2/.
What is Encapsulation?
Encapsulation is the ability to hide the internal workings of an object's behavior and its data. For instance,
let's say you have a object named Car and this object has a method (another word for behavior)
named start(). When you create an instance of a car object and call its start()
method you are not worried about what happens to accomplish this, you just want to make sure the state of the
car is changed to 'running' afterwards. This kind of behavior hiding is encapsulation and it makes programming
much easier. When you want your car object to be in a 'running' state, instead of calling: fuel.on(),
starter.on(), etc., you just call start(). This not only makes it easier to work
with, but if the internal workings of this start() method have to change, the results will be the same.
Encapsulation goes hand in hand with placing your code into a component and using this component when needed.
By placing the logic we need for similar processes into a component, we eliminate the need to rewrite that
code throughout an application every time the process has to be modified. When we need to make a change to
that process, we simply modify that component and the change is propagated throughout the application wherever
you used the component.
How Do We Apply This?
Ok, so now we have a general idea of what encapsulation means. But how do we apply this? With code of course.
For this article I have decided to use C#/ASP.NET. This is primarily because of ASP.NET's ability to use
Object-Oriented languages like C#. C# is very Java-like so it's pretty easy to pick up by someone like myself,
who has some experience with Java. If you have no experience with Java, C#, or C++, don't worry, I tried to
write the code examples as simple as possible, so hopefully you can pick it up quickly. To try and avoid
confusion I haven't tapped into the full power of C#, sacrificing efficiency for simplicity. So don't take the
example as the end all be all in coding. Simply recognize the use of encapsulation and our mission is accomplished.
(To help learn C#, be sure to read the articles in the C# Article Index!)
Here's our fictional Foo class below. It has a private String variable named _phoneNumber,
which we can set via the method setPhoneNumber(). We have no idea what is going on behind the
scenes when we call this method. It could be parsing the string data we entered and validating it. It could be
verifying it as correct in a Database. It doesn't matter because the internal logic for setting the phone
number is hidden from the developer. They simply create an object instance of this foo class and call the
method setPhoneNumber(), passing in a phone number as an argument.
Example Foo class below:
namespace KungFoo {
using System;
using System.Text;
public class Foo {
private String _phoneNumber;
public Foo(){
_phoneNumber = "703-567-8860";
}
public void setPhoneNumber(String strPhoneNumber){
_phoneNumber = strPhoneNumber;
}
public String getPhoneNumber(){
StringBuilder sb = new StringBuilder("Phone Number:");
sb.Append(_phoneNumber);
return sb.ToString();
}
}
}
|
Notice that we could have made a public property named .phoneNumber, but we chose not to. Instead
we use a method to alter the state of the object. Why you ask? What if instead of just setting a
phoneNumber property, we now have to also change a property named .hasPhone to TRUE
before the .phoneNumber property can be set. Everywhere this code was called from would have to
be changed. But we control the properties (state) by using our methods (behaviors). Behaviors should change/control
state of the object. This is good encapsulation.
In Part 2 we'll look at using the Foo class through
an ASP.NET page. By seeing how we'd use this class, we can see what benefits encapsulation brings to the table!
Read Part 2
