Talk:Information hiding

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.

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:

• Design by contract

---

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).

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)

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

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)

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?

what is "Example Information hiding?"

In the History section, second paragraph, the word "Example," which begins the first sentence, seems out of place, but I am not sufficiently familiar with this topic to boldly delete it. Bustter (talk) 23:08, 19 January 2010 (UTC)

Moving topic "Relation to object-oriented programming" to "Encapsulation" page

I think the Encapsulation (computer programming) page would be a better place for the section "Relation to object-oriented programming". Also, it doesn't seem to explain what it states in it's title. I will move the section until someone rejects this. Kaartic (talk) 16:06, 1 October 2016 (UTC)

Apparent conflation of implementation-hiding, information-hiding, and their applications.

Information-hiding, or data hiding, has traditionally been used for dual purposes of future-proofing (the same purpose as in implementation-hiding) and encapsulation (i.e. enforcement of invariants). This article's introduction only mentions the former. There is also a discussion on the talk page of encapsulation which promotes the conflation of data hiding and encapsulation. Encapsulation is distinct; the enforcement of invariants additionally employs exception safety (where applicable), synchronization, and a swathe of other programming constructs which are used to moderate the things that can occur both inside and outside privileged scopes. This page should present information hiding as a single, specific design construct which is used to express principles such as future-proofing and encapsulation, not as a principle in itself. 184.102.64.32 (talk) 07:52, 7 July 2020 (UTC)

Why is the change, confined to processes that follow change?

The term 'change'

was used incorrectly, 

and connected to one action= limiting. Misdirection, rather than 'hiding information' is a clearer message. Of course how does one explain how to think abstractively, two times? And do you mean two abstract streams of thought, or thoughts, at the same time? or do you mean, two streams of abstractive thinking stacked, one on top of the other? pstract'. It has no singular or plural, as it i, and it just spirals on and out and all around from there. Do you realise thw implications of pretending to be cahleva, in these 'meaning levelling' times?times? 49.194.46.174 (talk) 07:22, 29 May 2024 (UTC)

There is no logic

Once the words 'more general' have been read, how can anyone read on? For anything to change its sliding scale of the sliding scale, one might slide, right off the flipping scale? 49.194.46.174 (talk) 07:27, 29 May 2024 (UTC)