Information hiding
(5 intermediate revisions by 4 users not shown) | |||
Line 1: | Line 1: | ||
Information hiding firstly came out in a paper David Parnas wrote “On the Criteria to Be Used in Decomposing Systems Into Modules” (1972 ACM). Information hiding is all about hiding design and implementation decisions. | Information hiding firstly came out in a paper David Parnas wrote “On the Criteria to Be Used in Decomposing Systems Into Modules” (1972 ACM). Information hiding is all about hiding design and implementation decisions. | ||
− | In the object oriented design world, information hiding is the base concept for the well known encapsulation, modularity and abstraction. However, information hiding | + | In the object oriented design world, information hiding is the base concept for the well known encapsulation, modularity and abstraction. However, information hiding is not specific to any particular methodology; it can be used with any methodology or approaches including OO, procedural and functional programming. |
− | Information hiding has been recognized as a powerful technique for removing unnecessary software code rework, which | + | Information hiding has been recognized as a powerful technique for removing unnecessary software code rework, which become increasingly important during the life cycle of a software project. It helps to reduce unwanted code dependencies in large systems, which makes subsequent modifications to the code much easier. This is because clients of some module only need to be concerned with the interface of that module. The internal implementation of that module can change without affecting its clients. |
− | + | ||
− | + | ||
− | See the | + | When attempting to apply the principle of information hiding, it is essential to identify what you are trying to hide. This is typically some part of the system which is complicated and/or likely to require modification in the future. The next step is to specify an interface which is simple to use for the client, and not directly tied to the implementation. The clients then access the module through this interface and so doesn't need to be concerned about the implementation details. |
+ | |||
+ | == Parnas on the history & importance of Info Hiding == | ||
+ | |||
+ | See [[media:Parnas.pdf|Parnas Info Hiding talk]] in which Parnas claims information hiding is the basis of 3 more recent concepts: ADTs, OO and components. (Original found at [http://www.de.capgemini-sdm.com/download/sdm-konf2001/f_3_parnas.pdf| this web site].) | ||
+ | |||
+ | ==See also== | ||
+ | *[[Encapsulation]] | ||
+ | *[[Hide your decisions]] | ||
+ | *[[Object orgy]] | ||
+ | *[[Hide data within its class]] | ||
+ | |||
+ | {{Nomenclature}} | ||
+ | |||
+ | [[Category:Nomenclature]] |
Latest revision as of 23:30, 12 October 2009
Information hiding firstly came out in a paper David Parnas wrote “On the Criteria to Be Used in Decomposing Systems Into Modules” (1972 ACM). Information hiding is all about hiding design and implementation decisions.
In the object oriented design world, information hiding is the base concept for the well known encapsulation, modularity and abstraction. However, information hiding is not specific to any particular methodology; it can be used with any methodology or approaches including OO, procedural and functional programming.
Information hiding has been recognized as a powerful technique for removing unnecessary software code rework, which become increasingly important during the life cycle of a software project. It helps to reduce unwanted code dependencies in large systems, which makes subsequent modifications to the code much easier. This is because clients of some module only need to be concerned with the interface of that module. The internal implementation of that module can change without affecting its clients.
When attempting to apply the principle of information hiding, it is essential to identify what you are trying to hide. This is typically some part of the system which is complicated and/or likely to require modification in the future. The next step is to specify an interface which is simple to use for the client, and not directly tied to the implementation. The clients then access the module through this interface and so doesn't need to be concerned about the implementation details.
Parnas on the history & importance of Info Hiding
See Parnas Info Hiding talk in which Parnas claims information hiding is the basis of 3 more recent concepts: ADTs, OO and components. (Original found at this web site.)
See also
Nomenclature | |
---|---|
Techniques: Abstraction | Aggregation versus Composition | Association versus Dependency | Coupling | Encapsulation | Information hiding | Inheritance | Multiple Inheritance | Overloading | Polymorphism
Features: Abstract class | Class versus Object | Component versus Module | Instance | Interface | Method | Package versus Namespace | Superclass | Subclass |