Preventing unauthorized access to some piece of information or functionality.
The key money-saving insight is to separate the volatile part of some chunk of software from the stable part.
Encapsulation puts a firewall around the chunk, which prevents other chunks from accessing the volatile parts; other
chunks can only access the stable parts. This prevents the other chunks from breaking if (when!) the volatile parts are
changed. In context of OO software, a “chunk” is normally a class or a tight group of classes.
The “volatile parts” are the implementation details. If the chunk is a single class, the volatile part is normally
encapsulated using the
private
and/or protected
keywords. If the chunk is a tight group of
classes, encapsulation can be used to deny access to entire classes in that group.
Inheritance can also be used as a form of encapsulation.
The “stable parts” are the interfaces. A good interface provides a simplified view in the vocabulary of a
user, and is designed from the outside-in (here a “user” means another
developer, not the end-user who buys the completed application). If the chunk is a single class, the interface is
simply the class’s
public
member functions and friend
functions. If the chunk is a tight group of
classes, the interface can include several of the classes in the chunk.
Designing a clean interface and separating that interface from its implementation merely
allows users to use the interface. But encapsulating (putting “in a capsule”) the implementation forces users to use
the interface.
Thanks for a really good summary of the uses of blog very helpful as always.
ReplyDeleteOur site