Talk:Information hiding

From Wikipedia, the free encyclopedia

 This article is within the scope of WikiProject Computer science, which aims to create a comprehensive computer science reference for Wikipedia. Visit the project page for more information and to join in on related discussions.
Start rated as Start-Class on the assessment scale
Mid rated as Mid-importance on the assessment scale

Insertformulahere==Old copy== In computer science and object-oriented programming, encapsulation or modularity refers to how objects contain and manipulate data. Encapsulation (also referred to as, "information hiding") is the practice of hiding the data structures which represent the internal state of an object from access by anything other than the publicly-exposed methods of that object. This ensures that objects cannot change the internal state of other objects in unexpected ways, minimizing the complexity of putting together modules of code from different sources. 80908908089080890890890890 Encapsulated code can generally be rewritten without any need to rewrite the encapsulating code.

The two main advantages of encapsulation are:

  1. The data structure that represents the state can be reimplemented without affecting the implementation of the other objects. For example if the state of a point is represented internally with Cartesian coordinates then this might be changed to Polar coordinates without changing the interface of the object, i.e, without changing which messages with which arguments are understood by the object and what the type of the result of these messages will be.
  2. The state of the object can be guarded by the methods. The data structure that represents the state of the object may allow certain values that are not considered meaningful, e.g., a percentage may be represented by an integer that allows numbers larger than 100. The methods that update this integer can then ensure that it never rises above 100.

Many languages allow the programmer to bypass encapsulation, or to specify varying degrees of encapsulation for specific object types. In Java, for example, a class might be defined like this:

 class Cow extends Mammal {
   public Tail m_tail;
   private Horns m_horns;
   
   public void eat(Food f) {
     super.eat(f);
     chewcud();
   }
   private void chewcud() {
     . . .
   }
 }

With the Cow type as defined above, some piece of code external to Cow's implementation would be allowed to access m_tail directly, without going through any of the methods that Cow has chosen to expose as its interface. Such code would not, however, be able to access m_horns. Likewise, the method eat() is exposed as part of the Cow's interface, so any other object would be able to cause the cow object to eat by calling that method, passing it the offered food item as an argument to the method. External code would not be able to directly cause the cow to call its chewcud() method (nor would it even know such a method existed; only the cow itself knows or cares that eating involves chewing its cud).

More to be said about how various languages handle encapsulation.

See also:


I disagree with this definition (what described is not encapsulation, but data hiding), but I don't want to change it unless others agree with me. This is a fairly complicated subject, because "encapsulation" is a buzzword to begin with, with no fixed definition (or many definitions that disagree with one another). Nevertheless, defining encapsulation as different from data hiding seems much more useful. There's discussion on exactly this subject going on on the c2.com wiki: http://c2.com/cgi-bin/wiki?EncapsulationIsNotInformationHiding. Please read it and form your opinion. -- Lament



I disagree too. Encapsulation is a fundamental principles of object-oriented programming, though several object-oriented languages doesn't have any "public" and "private" notions (e.g. Python, Perl, and (not sure) Smalltalk).

Encapsulation is rather the fact of putting BOTH data (= attributes) and procedures (=methods) in the same "capsule" = the "object". But the "capsule" may be transparent or not, it is still a capsule.

See Encapsulation is not information hiding : http://www.javaworld.com/javaworld/jw-05-2001/jw-0518-encapsulation.html

Jiba -- jiba@tuxfamily.org

I've removed everything from the article that is encapsulation and left only the parts that are information hiding. Hopefully, that has addressed the concerns above. However, I will add encapsulation back in as a separate section in this article since encapsulation is so closely related and as far as I know, doesn't have a separate entry.

I will also include some examples of information hiding.. in particular, one where the principle of information hiding is employed outside of an object-oriented programming language (that is, information hiding without encapsulation).

Lastly, I will include some of the history of this if I can find some good sources. I know this principle has been around long before David Parnas published his seminal paper in 1972. However, Parnas often does receive the attribution for coining the term.

Kendrick

Consider the following definitions:

  • Encapsulation is the public interface that defines how an object can be used, and how its data is derived.
  • Information Hiding prevents external objects from using the derived data altogether.

This implies that Information Hiding without Encapsulation is not possible. Consider the following examples:

No Encapsulation and no Information Hiding (severely bad):

 class Mammal {
   public final static int EMPTY = 0;
   public final static int FULL = 1;
   public int tummy = EMPTY;
 }

Encapsulation and no Information Hiding (typically bad):

 class Mammal {
   public final static int EMPTY = 0;
   public final static int FULL = 1;
   private int tummy = EMPTY;
   
   public int getTummyStatus() {
     return this.tummy;
   }
   
   public void setTummyStatus( int status ) {
     this.tummy = status;
   }
 }

Encapsulation and Information Hiding (good):

 class Mammal {
   private final static int EMPTY = 0;
   private final static int FULL = 1;
   private int tummy = EMPTY;
   
   private int tummy() {
     return this.tummy;
   }
   
   private void tummy( int status ) {
     this.tummy = status;
   }
   
   public void eat() {
     tummy( FULL );
   }
   
   public void walk() {
     if( tummy() == FULL )
       tummy( EMPTY );
     else
       throw new ElfNeedsFoodBadly();
   }
 }

The object knows how to change itself, and does so without exposing its data to the rest of the world. As a consequence of both encapsulation and information hiding, the Mammal class may change how its tummy is used without affecting any other class in the system. For example, if hungriness was changed to a sliding scale (like gas in a car), then eat() and walk() could be modified to take the new sliding scale into consideration. Existing classes that used eat/walk would not need to change (whereas external classes that used either 'tummy' from the first example or 'getTummyStatus' from the second, would require changes).

Contents

[edit] Design decisions

In computer science, the principle of information hiding is the hiding of design decisions in a computer program that are most likely to change, thus protecting other parts of the program from change if the design decision is changed.

Aren't the decisions usually hidden implementation decisions rather than design decisions? - furrykef (Talk at me) 12:42, 6 Mar 2005 (UTC)

[edit] Very stupid article

My god, what idiotism/cretinism u can find in computer article!3 I cry. :^(

What the?
I like it how computer scientists always relate programming principles to some other kind of engineering procedure, even if the connection doesn't quite make sense. haha

[edit] Encapsulation issue.

I came to this article through the encapsulation disambiguation page. However, it seems that the very first reference to this term points back the same disambiguation page. What gives?? Folajimi(talk)

Be bold! I dunno. I think I put it in, probably without looking. Here, I'll be bold instead. --Mgreenbe 16:29, 26 January 2006 (UTC)

[edit] Another meaning for infomation hiding

What about the other meaning, where developers (usually consultants) will intentionally not divulge information to others, in an effort to make themselves appear indispensable?