Prima di OOP, i membri della struttura dei dati erano stati lasciati pubblici?

Quando una struttura di dati (ad esempio una coda) viene implementata utilizzando un linguaggio OOP, alcuni membri della struttura di dati devono essere privati ​​(ad esempio, il numero di elementi nella coda).

Una coda può anche essere implementata in un linguaggio procedurale usando ae structun insieme di funzioni che operano su struct. Tuttavia, in un linguaggio procedurale non è possibile rendere i membri di un structprivato. I membri di una struttura di dati implementati in un linguaggio procedurale sono stati lasciati pubblici o c'era qualche trucco per renderli privati?

OOP non ha inventato l'incapsulamento e non è sinonimo di incapsulamento. Molti linguaggi OOP non hanno modificatori di accesso in stile C ++ / Java. Molti linguaggi non OOP hanno varie tecniche disponibili per offrire l'incapsulamento.

Un approccio classico per l'incapsulamento sono le chiusure , utilizzate nella programmazione funzionale . Questo è significativamente più vecchio di OOP ma è in qualche modo equivalente. Ad esempio in JavaScript potremmo creare un oggetto come questo:

function Adder(x) {
  this.add = function add(y) {
    return x + y;
  }
}

var plus2 = new Adder(2);
plus2.add(7);  //=> 9

L' plus2oggetto sopra non ha alcun membro che consentirebbe l'accesso diretto a x- è interamente incapsulato. Il add()metodo è una chiusura sulla xvariabile.

Il linguaggio C supporta alcuni tipi di incapsulamento attraverso il meccanismo del file di intestazione , in particolare la tecnica del puntatore opaco . In C, è possibile dichiarare un nome di struttura senza definirne i membri. A quel punto nessuna variabile del tipo di quella struttura può essere usata, ma possiamo usare i puntatori a quella struttura liberamente (perché la dimensione di un puntatore alla struttura è nota al momento della compilazione). Ad esempio, considera questo file di intestazione:

#ifndef ADDER_H
#define ADDER_H

typedef struct AdderImpl *Adder;

Adder Adder_new(int x);
void Adder_free(Adder self);
int Adder_add(Adder self, int y);

#endif

Ora possiamo scrivere codice che utilizza questa interfaccia di Adder, senza avere accesso ai suoi campi, ad esempio:

Adder plus2 = Adder_new(2);
if (!plus2) abort();
printf("%d\n", Adder_add(plus2, 7));  /* => 9 */
Adder_free(plus2);

E qui ci sarebbero i dettagli dell'implementazione totalmente incapsulati:

#include "adder.h"

struct AdderImpl { int x; };

Adder Adder_new(int x) {
  Adder self = malloc(sizeof *self);
  if (!self) return NULL;
  self->x = x;
  return self;
}

void Adder_free(Adder self) {
  free(self);
}

int Adder_add(Adder self, int y) {
  return self->x + y;
}

Esiste anche la classe di linguaggi di programmazione modulari , che si concentra su interfacce a livello di modulo. La famiglia linguistica ML incl. OCaml include un approccio interessante ai moduli chiamati funzioni . OOP ha messo in ombra la programmazione modulare ampiamente utilizzata, ma molti presunti vantaggi di OOP riguardano più la modularità che l'orientamento agli oggetti.

C'è anche l'osservazione che le classi in linguaggi OOP come C ++ o Java spesso non vengono utilizzate per oggetti (nel senso di entità che risolvono operazioni mediante associazione tardiva / invio dinamico) ma semplicemente per tipi di dati astratti (dove definiamo un'interfaccia pubblica che si nasconde dettagli di implementazione interna). Il documento On Understanding Data Abstraction, Revisited (Cook, 2009) discute questa differenza in modo più dettagliato.

Sì, molte lingue non hanno alcun meccanismo di incapsulamento. In queste lingue, i membri della struttura vengono lasciati pubblici. Al massimo, ci sarebbe una convenzione di denominazione che scoraggia l'uso. Ad esempio, penso che Pascal non avesse un meccanismo di incapsulamento utile.

Innanzitutto, l'essere procedurali rispetto agli oggetti non ha nulla a che fare con pubblico vs privato. Molti linguaggi orientati agli oggetti non hanno nozione di controllo degli accessi.

In secondo luogo, in "C" - che la maggior parte delle persone chiamerebbe procedurale, e non orientata agli oggetti, ci sono molti trucchi che puoi usare per rendere effettivamente le cose private. Uno molto comune è usare puntatori opachi (es. Void *). Oppure: è possibile inoltrare un oggetto e non definirlo in un file di intestazione.

foo.h:

struct queue;
struct queue* makeQueue();
void add2Queue(struct queue* q, int value);
...

foo.c:

struct queue {
    int* head;
    int* head;
};
struct queue* makeQueue() { .... }
void add2Queue(struct queue* q, int value) { ... }

Guarda Windows SDK! Utilizza HANDLE e UINT_PTR, e cose del genere come handle generici della memoria utilizzata nelle API - rendendo effettivamente le implementazioni private.

"Tipi di dati opachi" era un concetto ben noto quando ho conseguito la laurea in informatica 30 anni fa. Non coprivamo OOP poiché all'epoca non era di uso comune e la "programmazione funzionale" era considerata più corretta.

Modula-2 aveva il supporto diretto per loro, vedi https://www.modula2.org/reference/modules.php .

Lewis Pringle ha già spiegato in che modo è possibile utilizzare in avanti la dichiarazione di una struttura in C. A differenza del Modulo 2, è stata fornita una funzione di fabbrica per creare l'oggetto. ( I metodi virtuali erano anche facili da implementare in C avendo il primo membro di una struttura come puntatore a un'altra struttura che conteneva puntatori di funzione ai metodi.)

Spesso veniva anche usata la convenzione. Ad esempio, non è possibile accedere a nessun campo che inizia con "_" al di fuori del file che possiede i dati. Ciò è stato facilmente applicato dalla creazione di strumenti di controllo personalizzati.

Ogni progetto su larga scala su cui ho lavorato (prima di passare a C ++ e poi C #) aveva un sistema in atto per impedire l'accesso ai dati "privati" con il codice sbagliato. Era solo un po 'meno standardizzato di adesso.

Nota che esistono molte lingue OO senza la possibilità integrata di contrassegnare i membri come privati. Questo può essere fatto per convenzione, senza che il compilatore debba applicare la privacy. Ad esempio, le persone spesso aggiungono il prefisso alle variabili private con un carattere di sottolineatura.

Esistono tecniche per rendere più difficile l'accesso alle variabili "private", la più comune delle quali è il linguaggio PIMPL . Questo mette le tue variabili private in una struttura separata, con solo un puntatore allocato nei tuoi file di intestazione pubblici. Ciò significa una maggiore dereferenza e un cast per ottenere qualsiasi variabile privata, qualcosa del genere ((private_impl)(obj->private))->actual_value, che diventa fastidioso, quindi in pratica viene usato raramente.

Le strutture dati non avevano "membri", solo campi di dati (supponendo che fosse un tipo di record). La visibilità era in genere impostata per l'intero tipo. Tuttavia, ciò potrebbe non essere così limitato come pensi, perché le funzioni non facevano parte del record.

Torniamo indietro e prendiamo un po 'di storia qui ...

Il paradigma di programmazione dominante prima di OOP era chiamato programmazione strutturata . L'obiettivo principale iniziale di questo era di evitare l'uso di istruzioni di salto non strutturate ("goto" s). Questo è un paradigma orientato al flusso di controllo (mentre OOP è più orientato ai dati), ma era comunque un'estensione naturale per tentare di mantenere i dati logicamente strutturati proprio come il codice.

Un altro risultato della programmazione strutturata è stato il nascondere le informazioni , l'idea che le implementazioni della struttura del codice (che probabilmente cambieranno abbastanza spesso) dovrebbero essere tenute separate dall'interfaccia (che idealmente non cambierebbe quasi altrettanto). Ora è dogma, ma ai vecchi tempi molte persone consideravano davvero migliore per ogni sviluppatore conoscere i dettagli dell'intero sistema, quindi questa volta era in realtà un'idea controversa. L'edizione originale di The Mythical Man Month di Brook ha effettivamente discusso contro il nascondiglio delle informazioni.

I linguaggi di programmazione successivi progettati esplicitamente per essere buoni linguaggi di programmazione strutturata (ad esempio, Modula-2 e Ada) generalmente includevano il nascondere le informazioni come un concetto fondamentale, costruito attorno a un qualche tipo di concetto di una funzione coesiva di funzioni (e qualsiasi tipo, costante e oggetti che potrebbero richiedere). In Modula-2 questi erano chiamati "Moduli", in "Pacchetti" di Ada. Molti linguaggi OOP moderni chiamano lo stesso concetto "spazi dei nomi". Questi spazi dei nomi erano il fondamento organizzativo dello sviluppo in questi linguaggi e per la maggior parte degli scopi potevano essere usati in modo simile alle classi OOP (senza supporto reale per l'eredità, ovviamente).

Quindi, in Modula-2 e Ada (83) si poteva dichiarare qualsiasi routine, tipo, costante, o un oggetto in uno spazio dei nomi privato o pubblico, ma se si ha un tipo di record, non c'era (facile) modo per dichiarare alcuni record di campi pubblici e altri privati. O tutto il tuo disco è pubblico o non lo è.

In C potresti già passare i puntatori a tipi dichiarati ma non definiti, come altri hanno già detto, limitando in effetti l'accesso a tutti i campi.

Puoi anche avere funzioni pubbliche e private da un modulo all'altro. Le funzioni dichiarate statiche nel file di origine non sono visibili all'esterno, anche se si tenta di indovinarne il nome. Allo stesso modo, puoi avere variabili globali statiche a livello di file, il che è generalmente una cattiva pratica ma consente l'isolamento su base modulo.

È probabilmente importante sottolineare che la restrizione dell'accesso come una convenzione ben standardizzata piuttosto che un costrutto imposto dal linguaggio funziona bene (vedi Python). Inoltre, la limitazione dell'accesso ai campi oggetto protegge il programmatore solo quando è necessario modificare il valore dei dati all'interno di un oggetto dopo la creazione. Che è già un odore di codice. Probabilmente, la constparola chiave di C e in particolare la parola chiave di C ++ per metodi e argomenti di funzione è di gran lunga più utile per il programmatore rispetto a quella piuttosto scarsa di Java final.

Se la tua definizione di pubblico è la capacità di accedere all'implementazione e ai dati / proprietà tramite il tuo codice in qualsiasi momento, la risposta è semplicemente: Sì . Tuttavia, è stato astratto con diversi mezzi, a seconda della lingua.

Spero che questo abbia risposto brevemente alla tua domanda.

Ecco un contro-esempio molto semplice: in Java, interfacedefiniamo gli oggetti, ma classnon lo fanno. A classdefinisce un tipo di dati astratto, non un oggetto.

Ergo, ogni volta che lo usi privatein classJava, hai un esempio di una struttura di dati con membri privati ​​che non è orientata agli oggetti.