Information hiding

From CSSEMediaWiki
(Difference between revisions)
Jump to: navigation, search
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 does not necessarily base on any particular methodology; it can be used with any methodology or approaches.
+
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 brings huge benefit in the software evolving life cycle. It helps to reduce unwanted code dependencies in a large sized system, which makes later modifying a legacy code become much pleasant work since programmer only need to concern the hidden logic part rather than the usage of that particular logic within the entire application.
+
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 you put information hiding into use, the starting point is to find out what part of the design is the design secret which you want to hide from others. These secrets are always within the part of the design which will always change (or possibly be changed very often). The further isolation or abstraction methodology can be applied to these parts to achieve information hiding.
+
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.

See also

Personal tools