3. Information hiding

Il concetto di information hiding (che potremmo tradurre con "occultamento di informazione") nella OOP implicito in quello di ADT  e consiste nell'idea che l'utente di un servizio tenuto a conoscere solo le  informazioni strettamente necessarie per l'usufruizione del servizio.  Ogni altra informazione pu confondere l'utente e/o mettere a rischio l'integrità dell'oggetto stesso.

Tecnicamente si afferma che l'utente deve conoscere solo l' interfaccia della classe, cio il suo nome e l'interfaccia di ciascuna proprietà pubblica.

Alcuni sistemi sono in grado di estrarre/documentare automaticamente l'interfaccia di classe dalla definizione completa di un classe. 

In realtà esiste un altro importante vantaggio dell'information hiding: l'implementatore di una classe potrà ritenersi libero di effettuare delle migliorie senza che questo comporti delle modifiche ai programmi clienti, ciò che usino i servizi offerti da quella classe. L'information hiding quindi determinante non solo per semplificare la vita ai programmatori, ma anche per la manutenzione e il "riuso del software".

In particolare, nella OOP, l'informazione da  nascondere la rappresentazione dello stato dell'oggetto, ciò  l'insieme degli attributi. A rigore, quindi, tutti gli attributi dovrebbero essere nascosti: l'utente deve potervi accedere solo indirettamente attraverso i metodi. Tuttavia,  per motivi di efficienza, alcuni linguaggi ad oggetti (tra cui  C++, Java e Delphi) permettono l'accesso agli attributi (sia in lettura che in scrittura).  Il problema dell'information hiding viene risolto in questi linguaggi permettendo l'accesso solo ad alcuni attributi classificati come pubblici (tipicamente saranno quelli presenti in tutte le possibili rappresentazioni). Oltre agli attributi si possono nascondere anche metodi. Tipico il caso dei metodi ausiliari, ciò utilizzati per implementare i metodi pubblici, e pi in generale, di tutti quei metodi la cui esistenza  legata alla rappresentazione scelta.

In generale, ogni linguaggio propone proprie soluzioni al problema della visibilità, ciò di come stabilire a quali classi rendere visibili le proprietà (sia attributi che metodi) di una classe. A titolo puramente  indicativo possiamo citare la soluzione a tre livelli del C++:

proprietà pubbliche: tutte le classi possono accedervi

proprietà protette: solo le sottoclassi possono accedervi

proprietà private: nessuna classe può accedervi

Infatti, per questioni di flessibilità ed efficienza, si sente la necessità di poter definire diversi "livelli" di visibilità. L'ideale poter decidere per ogni proprietà, quali sono le classi che possono accedervi. L'ereditarietà, in particolare, pone un problema che occorre risolvere di volta in volta: quali proprietà ereditate di una classe devono essere nascoste alle sue sottoclassi ? alcuni linguaggi (ad es. C++ e Java) danno questa risposta: quelle pubbliche e quelle dichiarate appunto come "protette". Altri (ad es. Eiffel) sostengono la tesi che tutto quello che visibile all'implementatore di  una classe deve essere visibile anche  agli implementatori delle sue sottoclassi. Inoltre Eiffel non permette la modalità "private", sostenendo il punto di vista secondo cui l'implementatore di una classe non può decidere arbitrariamente che alcuni attributi non siano utili agli implementatori delle sottoclassi.