Information hiding
JaninaVoigt (Talk | contribs) |
|||
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. |
− | + | ||
− | When | + | 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. |
==See also== | ==See also== | ||
*[[Hide your decisions]] | *[[Hide your decisions]] | ||
*[[Object orgy]] | *[[Object orgy]] |
Revision as of 06:33, 29 July 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.