REALbasic Cross-Platform Application Development

The idea of encapsulation is that an object does a lot of things privately that no one else needs to know about.

The Public methods of an object provide an interface to the outside world. It exposes the methods that can be called by other objects in your program. These typically aren't all the methods that compose the object because the object itself has lots of little details to attend to.

It's kind of like the drive-up window at a fast-food restaurant. When I pull up, the first thing I encounter is the menu that tells me what I can order; then there's the staticky speaker that I talk into to place my order. After ordering, I proceed to the first window to pay, then go to the second window to pick up my food, and then drive off.

A fast-food restaurant is encapsulated. It provides a means for me to place an order and pick it up, but I don't really have any idea what's going on inside, except that I know that when I place an order, it triggers a sequence of events inside the restaurant that results in food being handed over to me at the second window.

There's a fast-food restaurant near my house that I go to all the time. I do the same thing every time I go, and even order the same food (I'm a creature of habit). Even though my experience with the restaurant doesn't change, for all I know, they could have hired a consultant last week who showed them a new way to make hamburgers that was more cost efficient and would save them lots of money. I don't know about it and don't really need to know about it. As long as the steps I take to order the food are the same and the hamburger I order tastes the same, I really don't care.

Sometimes encapsulation is described in a slightly different way. These developers say that encapsulation means that an object should know how to do all the important things required to do its job. So if you create a class that represents a square, the class should also be able to display that square in a window or print that square on a sheet of paper. Although it's true that the class should group together related properties and methods that function as a unit, you shouldn't infer that the class needs to know about and be able to do everything related to it. If you follow that logic to the bitter end, all your programs will just be one gigantic class, and that defeats the purpose.

In practice, people often organize their classes quite differently. Some objects you use in your program will have only properties and no methods at all, which means that they don't know anything about themselves other than the data they represent. That's not a violation of the principle of encapsulation.

The fast-food restaurant I frequent doesn't slaughter its own cattle, grind it up in the back room, and cook my patties all the in same place. They hire someone to provide the ground-up meat. They "outsource." Classes and objects outsource, too. Often, a class is just a collection of other classes.

We'll dispense with the concepts for a moment. There's a practical side to object-oriented programming, too. Your goal is to create a program that maximizes code reuse, so you don't spend your life doing the same thing over and over. You also want a program that is easy to change in the future so that if something goes wrong, it's easy to figure out what it is that goes wrong. These factors are as important, and maybe more so, as the conceptual purity of your object model.

For example, I have a program that I use to write books and create websites. In fact, I'm using it right now. The "documents" I create will end up in print and sometimes online in different formats. Some of the documents are retrieved off of the file systems, others are pulled from Subversion, others are opened up using an HTTP request over the web.

If I took the encapsulation advice offered by some, I would have methods in my document class for opening files from the file system, from Subversion or through the web within the document class. However, because I know that I may be adding additional sources of data in the future, in different formats, which means I would have to go back and continue to add to this class, making it bigger and more complex over time, I created a group of classes. One group represents the data in the documents, another group handles getting the data from different sources, and a third group handles writing the documents out into different formats. If I have a new data source, I just subclass my Provider class and override the open method. I don't have to change the document class.