Perché le variabili private sono descritte nel file di intestazione accessibile al pubblico?

OK, quindi spero che questa sia una domanda abbastanza soggettiva per i programmatori, ma qui va. Allargo continuamente la mia conoscenza delle lingue e delle pratiche di ingegneria del software ... e mi sono imbattuto in qualcosa che per me non ha assolutamente senso.

In C ++, le dichiarazioni di classe includono private:metodi e parametri nel file di intestazione, che, in teoria, è ciò che passi all'utente da includere se le rendi lib.

In Objective-C, @interfacefacciamo praticamente la stessa cosa, costringendoti a elencare i tuoi membri privati ​​(almeno, c'è un modo per ottenere metodi privati ​​nel file di implementazione).

Da quello che posso dire, Java e C # consentono di fornire un'interfaccia / protocollo che può dichiarare tutte le proprietà / i metodi accessibili al pubblico e offre al programmatore la possibilità di nascondere tutti i dettagli dell'implementazione nel file di implementazione.

Perché? L'incapsulamento è uno dei principi principali di OOP, perché C ++ e Obj-C mancano di questa capacità di base? Esiste una sorta di soluzione ottimale per Obj-C o C ++ che nasconde tutta l' implementazione?

Grazie,

La domanda è se il compilatore deve sapere quanto è grande un oggetto. In tal caso, il compilatore deve conoscere i membri privati ​​per poterli contare.

In Java, ci sono tipi e oggetti primitivi e tutti gli oggetti sono allocati separatamente e le variabili che li contengono sono in realtà puntatori. Pertanto, poiché un puntatore è un oggetto a dimensione fissa, il compilatore sa quanto è grande una variabile, senza conoscere la dimensione effettiva dell'oggetto puntato. Il costruttore gestisce tutto ciò.

In C ++, è possibile avere oggetti rappresentati localmente o nell'heap. Pertanto, il compilatore deve sapere quanto è grande un oggetto, in modo da poter allocare una variabile o matrice locale.

A volte è desiderabile dividere la funzionalità della classe in un'interfaccia pubblica e in qualsiasi altra cosa privata, ed è qui che entra in gioco la tecnica PIMPL (Pointer to IMPLementation). La classe avrà un puntatore a una classe di implementazione privata e i metodi della classe pubblica possono chiamare quello.

A causa della progettazione di C ++, per creare un oggetto nello stack il compilatore deve sapere quanto è grande. Per fare ciò deve avere tutti i campi presenti nel file di intestazione, poiché è tutto ciò che il compilatore può vedere quando l'intestazione è inclusa.

Ad esempio se si definisce una classe

class Foo {
    public int a;
    private int b;
};

allora sizeof(Foo)è sizeof(a) + sizeof(b). Se esistesse un meccanismo per separare i campi privati, l'intestazione potrebbe contenere

class Foo {
    public int a;
};

con sizeof(Foo) = sizeof(a) + ???.

Se vuoi davvero nascondere i dati privati, prova il linguaggio del pimpl, con

class FooImpl;
class Foo {
    private FooImpl* impl;
}

nell'intestazione e una definizione FooImplsolo per Fooil file di implementazione.

Tutto questo dipende dalla scelta del design.

Se desideri veramente nascondere i dettagli dell'implementazione privata della classe C ++ o Objective-C, allora fornisci una o più interfacce supportate dalla classe (classe virtuale pura C ++, protocollo Objective-C) e / o crea la classe in grado di costruirsi da solo fornendo un metodo factory statico o un oggetto factory di classe.

Il motivo per cui le variabili private sono esposte nel file di intestazione / dichiarazione di classe / interfaccia @ è che un consumatore della tua classe potrebbe aver bisogno di crearne una nuova istanza e un new MyClass()o [[MyClass alloc]init]nel codice client necessita del compilatore per capire quanto sia grande una MyClass oggetto è per fare l'allocazione.

Java e C # hanno anche le loro variabili private dettagliate nella classe - non fanno eccezione, ma IMO il paradigma dell'interfaccia è molto più comune con quei linguaggi. Potresti non avere il codice sorgente in ogni caso, ma ci sono abbastanza metadati nel codice compilato / byte per dedurre queste informazioni. Poiché C ++ e Objective-C non dispongono di questi metadati, l'unica opzione sono i dettagli effettivi dell'interfaccia class / @. Nel mondo COM C ++, non si espongono le variabili private di nessuna classe, tuttavia è possibile fornire il file di intestazione, poiché la classe è pura virtuale. Un oggetto factory di classe è registrato per creare anche le istanze effettive e ci sono alcuni metadati in varie forme.

In C ++ e Objective-C, è meno difficile distribuire il file di intestazione rispetto alla scrittura e alla gestione di un file di interfaccia / protocollo aggiuntivo. Questo è uno dei motivi per cui l'implementazione privata è esposta così spesso.

Un altro motivo in C ++ è rappresentato dai modelli: il compilatore deve conoscere i dettagli della classe per generare una versione di quella classe specializzata nei parametri forniti. La dimensione dei membri della classe varierebbe con la parametrizzazione, quindi deve avere queste informazioni.