Encapsulation essentially means that any information regarding the implementation of a class is hidden from the user of a class. The implementation is wrapped -- encapsulated -- by the interface and the split between the two is absolute. This serves many purposes.
For one, code is more easily maintained. The interface of a class is essentially a contract between the class developer and the application developer using the class. The class developer is setting out in clear terms how the class will behave, and what methods are available. When you, the application developer, program using the class, you adhere to the interface. The net effect of this is that the class developer can freely maintain, or upgrade the class implementation without worrying about breaking anyone's applications -- as long as he too adheres to the interface he provided.
A classic example of the separation of interface and implementation are telephones. For years now, the telephone has had the same basic interface -- a handset and dial with 12 buttons. However, the phone companies have always upgraded their systems making them faster or more reliable or whatever they do. But the point is: The interface never changes. When phone networks went digital you didn't have to relearn how to use a phone. The same idea is at work with classes. You learn them once and the implementers can go about their business. It really is a wonderful way of running things.
Before I finish, I'd like to talk to you about a subtle effect of the way objects and object-oriented languages are built that gives this technology much of its power. It's called polymorphism. What this means is that many classes can -- and will -- contain and implement methods with the same name.
Also in Programming With Cocoa:
Clearly one of the benefits of polymorphism is that you, the developer, have a smaller vocabulary of methods to remember to access core functionality. For example, in the Application Kit, many classes implement methods such as
floatValue which return numerical values when invoked.
Since many objects implement methods by the same name, it's possible to dynamically select message receivers at runtime. Let's go back to our hypothetical graphics program to illustrate this. Like any modern application, we want to implement cutting and pasting. So whenever the "cut" command is chosen, a "cut" message is sent to the selected objects on screen causing them to be stored on the clipboard.
The key word here is "selected." Obviously you can't hard-code the message before compilation to send a cut message to an object in your drawing. Rather, the receiver of the "cut" message sent by the "cut" command is selected beforehand by clicking and selecting an object on screen. It is dynamically created at runtime in response to the users actions! For this to work, however, every object that could potentially appear onscreen as a part of your drawing must implement a customized version of the "cut" method.
In the next column, I will tell you about how Objective-C implements the concepts I've covered today, as well as showing you what Objective-C code actually looks like. Don't miss it!
Michael Beam is a software engineer in the energy industry specializing in seismic application development on Linux with C++ and Qt. He lives in Houston, Texas with his wife and son.
Read more Programming With Cocoa columns.
Return to the Mac DevCenter.