Nothing Special   »   [go: up one dir, main page]

0% found this document useful (0 votes)
37 views3 pages

Encapsulation: Object-Oriented Design Grady Booch

Download as doc, pdf, or txt
Download as doc, pdf, or txt
Download as doc, pdf, or txt
You are on page 1/ 3

Encapsulation

Encapsulation is a way of organising data and methods into a structure by concealing the the way the object is implemented, i.e. preventing access to data by any means other than those specified. Encapsulation therefore guarantees the integrity of the data contained in the object. In his influential book on object-oriented design, Grady Booch defined encapsulation as "the process of compartmentalizing the elements of an abstraction that constitute its structure and behavior; encapsulation serves to separate the contractual interface of an abstraction and its implementation." This formulation is cited by a number of books as an authoritative definition of encapsulation. The purpose is to achieve potential for change: the internal mechanisms of the component can be improved without impact on other components, or the component can be replaced with a different one that supports the same public interface. Encapsulation also protects the integrity of the component, by preventing users from setting the internal data of the component into an invalid or inconsistent state. Another benefit of encapsulation is that it reduces system complexity and thus increases robustness, by limiting the interdependencies between software components. In this sense, the idea of encapsulation is more general than how it is applied in OOP: for example, a relational database is encapsulated in the sense that its only public interface is a Query Language (SQL for example), which hides all the internal machinery and data structures of the database management system. As such, encapsulation is a core principle of good software architecture, at every level of granularity. Encapsulating software behind an interface allows the construction of objects that mimic the behavior and interactions of objects in the real world. For example, a simple digital alarm clock is a real-world object that a lay person can use and understand. They can understand what the alarm clock does, and how to use it through the provided interface (buttons and screen), without having to understand every part inside of the clock. Similarly, if you replaced the clock with a different model, the lay person could continue to use it in the same way, provided that the interface works the same. In the more concrete setting of an object-oriented programming language, the notion is used to mean either an information hiding mechanism, a bundling mechanism, or the combination of the two.

Concealing data

The user of a particular class does not need to know how the data in that object is structured, this means that a user does not need to know how implementation takes place. By preventing the user from directly modifying attributes, and forcing the user to use defined functions in order to modify them (calledinterfaces), data integrity is thus ensured (for example, one can ensure that the data type given matches expectations, or is returned within the expected time interval). Encapsulation defines the access levels for elements of that class. These access levels define the access rights to the data, allowing us to access the data by a method of that particular class itself, from an inheritance class, or even from any other class. There are three levels of access: public: functions of all classes may access the data or methods of a class that is defined with thepublic access level. This is the lowest level of data protection protected: data access is restricted to functions of inheritance classes, i.e. member functions of that class and all sub-classes private: data access is restricted to methods of that particular class only. This is the highest level of data protection

As information hiding mechanism


Under this definition, encapsulation means that the internal representation of an object is generally hidden from view outside of the object's definition. Typically, only the object's own methods can directly inspect or manipulate its fields. Some languages like Smalltalk and Ruby only allow access via object methods, but most others (e.g. C++ or Java) offer the programmer a degree of control over what is hidden, typically via keywords like public and private. It should be noted that the ISO C++ standard refers to private and publicas "access specifiers" and that they do not "hide any information". Information hiding is accomplished by furnishing a compiled version of the source code that is interfaced via a header file. Hiding the internals of the object protects its integrity by preventing users from setting the internal data of the component into an invalid or inconsistent state. A benefit of encapsulation is that it can reduce system complexity, and thus increases robustness, by allowing the developer to limit the interdependencies between software components. Almost always there is a way to override such protection - usually via reflection API (Ruby, Java, C# etc.), sometimes by mechanism like name mangling (Python), or special keyword like friend in C++. This access is often necessary for debuggers, serialization, unit testing, but not uncommonly in normal code when private was overeagerly applied.

This mechanism is not unique to object-oriented programming. Implementations of abstract data types, e.g. modules offer a similar form of encapsulation. This similarity stems from the fact that both notions rely on the same mathematical fundament of an existential type.

You might also like