classe in lingua e tipo OOP

Nella teoria del linguaggio di programmazione, un tipo è un insieme di valori. Ad esempio, il tipo "int" è l'insieme di tutti i valori interi.

Nei linguaggi OOP, una classe è un tipo, vero?

Quando viene definita una classe con più di un membro, ad es

class myclass{
    int a; 
    double b;
}

Quando parliamo di una lezione, intendiamo

• " (a,b)dove aè un int ed bè un doppio", oppure
• "{ (x,y)| xè un int, yè un doppio}"?

Cosa significa un'istanza di myclass?

• " (a,b)dove aè un int ed bè un doppio", oppure
• un oggetto che occupa uno spazio di memoria e che può (non necessariamente, cioè può essere vuoto) memorizzare (x,y), dov'è xqualsiasi int ed yè un doppio?

Nessuno dei due.

Suppongo che tu stia chiedendo se avere lo stesso set di tipi di campo sia sufficiente per classificarlo come la stessa classe o se debbano essere nominati in modo identico. La risposta è: "Non basta nemmeno avere gli stessi tipi e gli stessi nomi!" Le classi strutturalmente equivalenti non sono necessariamente compatibili con il tipo.

Ad esempio, se si dispone di una CartesianCoordinatese una PolarCordinatesclasse, potrebbero avere entrambi due numeri nei rispettivi campi e potrebbero persino avere lo stesso Numbertipo e gli stessi nomi, ma non sarebbero comunque compatibili e un'istanza di PolarCoordinatesnon sarebbe un istanza di CartesianCoordinates. La capacità di separare i tipi in base allo scopo previsto e non all'implementazione corrente è una parte molto utile per scrivere codice più sicuro e più gestibile.

I tipi non sono insiemi.

Vedete, la teoria degli insiemi ha una serie di caratteristiche che semplicemente non si applicano ai tipi e viceversa . Ad esempio, un oggetto ha un solo tipo canonico. Può essere un'istanza di diversi tipi diversi, ma solo uno di questi tipi è stato utilizzato per istanziarlo. La teoria degli insiemi non ha nozioni di insiemi "canonici".

La teoria degli insiemi ti consente di creare sottoinsiemi al volo , se hai una regola che descrive ciò che appartiene al sottoinsieme. La teoria dei tipi generalmente non lo consente. Mentre la maggior parte delle lingue ha un Numbertipo o qualcosa di simile, non ne ha un EvenNumbertipo, né sarebbe semplice crearne uno. Voglio dire, è abbastanza facile definire il tipo stesso, ma qualsiasi Numbers esistente che si presenta anche non verrà trasformata magicamente in EvenNumbers.

In realtà, dire che è possibile "creare" sottoinsiemi è un po 'disonesto, perché gli insiemi sono un diverso tipo di animale. Nella teoria degli insiemi, questi sottoinsiemi esistono già , in tutti gli infiniti modi in cui puoi definirli. Nella teoria dei tipi, di solito ci aspettiamo di avere a che fare con un numero finito (se grande) di tipi in un dato momento. Gli unici tipi che si dice esistano sono quelli che abbiamo effettivamente definito, non tutti i tipi che potremmo definire.

Gli insiemi non possono contenere direttamente o indirettamente se stessi . Alcuni linguaggi, come Python, forniscono tipi con strutture meno regolari (in Python, typeil tipo canonico è typeed objectè considerato un'istanza di object). D'altra parte, la maggior parte delle lingue non consente ai tipi definiti dall'utente di impegnarsi in questo tipo di inganno.

Gli insiemi possono comunemente sovrapporsi senza essere contenuti l'uno nell'altro. Questo è raro nella teoria dei tipi, sebbene alcune lingue lo supportino sotto forma di eredità multipla. Altre lingue, come Java, consentono solo una forma limitata di questo o non lo consentono del tutto.

Il tipo vuoto esiste (si chiama il tipo in basso ), ma la maggior parte delle lingue non lo supporta o non lo considera un tipo di prima classe. Esiste anche il "tipo che contiene tutti gli altri tipi" (si chiama il tipo superiore ) ed è ampiamente supportato, diversamente dalla teoria degli insiemi.

NB : Come alcuni commentatori hanno precedentemente sottolineato (prima che il thread fosse spostato in chat), è possibile modellare i tipi con la teoria degli insiemi e altri costrutti matematici standard. Ad esempio, è possibile modellare l'appartenenza al tipo come relazione anziché modellare i tipi come set. Ma in pratica, questo è molto più semplice se usi la teoria delle categorie invece della teoria degli insiemi. Ecco come Haskell modella la sua teoria dei tipi, per esempio.

La nozione di "sottotipizzazione" è molto diversa dalla nozione di "sottoinsieme". Se Xè un sottotipo di Y, significa che possiamo sostituire istanze di Yper istanze di Xe il programma continuerà a "funzionare" in un certo senso. Questo è comportamentale piuttosto che strutturale, sebbene alcune lingue (es. Go, Rust, probabilmente C) abbiano scelto quest'ultima per ragioni di convenienza, sia per il programmatore che per l'implementazione del linguaggio.

I tipi di dati algebrici sono il modo di discuterne.

Esistono tre modi fondamentali per combinare i tipi:

• Prodotto. Questo è fondamentalmente quello a cui stai pensando:

  struct IntXDouble{
    int a; 
    double b;
  }
  

  è un tipo di prodotto; i suoi valori sono tutte le possibili combinazioni (es. tuple) di uno inte uno double. Se si considerano i tipi di numero come set, la cardinalità del tipo di prodotto è in realtà il prodotto delle cardinalità dei campi.

• Somma. Nei linguaggi procedurali questo è un po 'imbarazzante da esprimere direttamente (in genere è fatto con i sindacati con tag ), quindi per una migliore comprensione, ecco un tipo di somma in Haskell:

  data IntOrDouble = AnInt Int
                   | ADouble Double
  

  i valori di questo tipo hanno il modulo AnInt 345o ADouble 4.23, ma c'è sempre un solo numero coinvolto (diversamente dal tipo di prodotto, dove ogni valore ha due numeri). Quindi la cardinalità: prima elenchi tutti i Intvalori, ognuno deve essere combinato con il AnIntcostruttore. Inoltre , tutti i Doublevalori, ciascuno combinato con ADouble. Quindi tipo di somma .

• Esponenziazione ¹ . Non ne parlerò in dettaglio qui perché non ha alcuna chiara corrispondenza OO.

E le lezioni? Ho deliberatamente usato la parola chiave structanziché classper IntXDouble. Il fatto è che una classe come tipo non è in realtà caratterizzata dai suoi campi, questi sono semplicemente dettagli di implementazione. Il fattore cruciale è piuttosto, quali valori distinguibili può avere la classe.

Ciò che è rilevante è che il valore di una classe può essere il valore di una qualsiasi delle sue sottoclassi ! Quindi una classe è in realtà un tipo di somma piuttosto che un tipo di prodotto: se Ae Bda cui entrambi sarebbero derivati myClass, myClasssarebbe essenzialmente la somma di Ae B. Indipendentemente dall'attuazione effettiva.

¹ _{Queste sono funzioni (in senso matematico! ); un tipo di funzione Int -> Doubleè rappresentato dall'esponenziale Double^Int. Peccato se la tua lingua non ha funzioni adeguate ...}

Scusa ma non conosco la teoria "grezza". Posso solo fornire un approccio pratico. Spero che questo sia accettabile su programmers.SE; Non ho familiarità con l'etichetta qui.

Un tema centrale di OOP è nascondere le informazioni . Quali siano esattamente i membri dei dati di una classe non dovrebbero interessare i suoi clienti. Un client invia messaggi a (chiama metodi / funzioni membro di) un'istanza, che potrebbe o meno modificare lo stato interno. L'idea è che gli interni di una classe potrebbero cambiare, senza che il client ne sia influenzato.

Un correlativo a questo è che la classe è responsabile di garantire che la sua rappresentazione interna rimanga "valida". Supponiamo che una classe memorizzi un numero di telefono (semplificato) in due numeri interi:

    int areacode;
    int number;

Questi sono i membri dei dati della classe. Tuttavia, la classe sarà probabilmente molto più che solo i suoi membri di dati, e certamente non è definibile come "insieme di tutti i possibili valori di int x int". Non dovresti avere accesso diretto ai membri dei dati.

La costruzione di un'istanza potrebbe negare qualsiasi numero negativo. Forse la costruzione avrebbe anche normalizzato il prefisso in qualche modo, o addirittura verificato l'intero numero. In questo modo finiresti molto più vicino al tuo "(a,b) where a is an int and b is a double", perché certamente non ci sono due int memorizzati in quella classe.

Ma non importa davvero per quanto riguarda la classe. Non è il tipo di membri dei dati, né l'intervallo dei loro possibili valori che definisce la classe, sono i metodi che sono definiti per essa.

Fintanto che tali metodi rimangono gli stessi, l'implementatore potrebbe cambiare i tipi di dati in virgola mobile, BIGNUM, stringhe, qualunque cosa, e per tutti gli scopi pratici, rimarrebbe comunque la stessa classe .

Esistono schemi di progettazione per garantire che tali modifiche della rappresentazione interna possano essere apportate senza che il client ne sia nemmeno a conoscenza (ad esempio il linguaggio del pimpl in C ++, che nasconde tutti i membri dei dati dietro un puntatore opaco ).

• Un tipo è una descrizione di una categoria / intervallo di valori, strutture composte o cosa hai. OOPwise, è simile a una "interfaccia". (Nel senso agnostico del linguaggio. Il senso specifico del linguaggio, non tanto. In Java, ad esempio, intè un tipo , ma non ha alcuna relazione con un interface. Le specifiche del campo pubblico / protetto, inoltre, non fanno parte di un interface, ma fanno parte di una "interfaccia" o tipo .)

  Il punto principale è che è molto più una definizione semantica che una concreta. La struttura prende in considerazione solo i fattori in quanto i campi / comportamenti esposti e i loro scopi definiti si allineano. Se non si dispone di entrambi, non si dispone della compatibilità dei tipi.

• Una classe è la realizzazione di un tipo. È un modello che definisce effettivamente la struttura interna, il comportamento associato, ecc.