Perché le classi implicitamente derivano da solo l'oggetto di classe?

Question

Non ho nessun argomento opporsi perché abbiamo bisogno di una sola classe universale. Tuttavia perché non ci sono due classi universali, diciamo un oggetto e una classe di AntiObject. In natura e nella scienza troviamo il concetto di dualità - come Energy & Dark Energy; Maschio femmina; Più meno; Multiply & Divide; Gli elettroni e protoni; Integrazione e derivazione; e nella teoria degli insiemi. Ci sono tanti esempi di dualismo che si tratta di una filosofia in sé. Nella programmazione per sé vediamo anti-pattern che ci aiuta a svolgere un lavoro a differenza di come utilizziamo design pattern. Non sono sicuro, ma l'utilità di questo concetto dualità potrebbe risiedere nella creazione munnizzari che creano AntiObjects che si combinano con gli oggetti liberi o allentati di distruggere se stessi, così liberando memoria. O può essere AntiObjects lavorano insieme con gli oggetti per creare un linguaggio di programmazione di auto-modifica - che ci permette di creare un codice di autoregolamentazione modifica al sicuro, fanno di calcolo evolutivo utilizzando la programmazione genetica, fanno nasconde di codice per impedire il reverse engineering.

Lo chiamiamo programmazione orientata agli oggetti. E 'questo un fattore limitante o c'è qualcosa di fondamentale che mi manca nella comprensione della formazione dei linguaggi di programmazione?

Answer 1

Questa è solo una risposta per rispondere alla domanda nel titolo.

Linguaggi come Java hanno ogni classe che deriva da Object per due motivi.

In primo luogo, per aumentare la quantità di polimorfismo a disposizione. Questo è stato particolarmente richiesto prima generici sono stati aggiunti alla lingua. Senza oggetti, classi di insiemi sarebbe impossibile scrivere in un modo utile.

In secondo luogo, ci sono molti metodi che le classi sono attesi per avere o sono utili, e questi vengono raccolti in oggetto. Facendo in modo che tutte le classi ereditano da Object, tutte le classi implementare la stessa interfaccia minimale.

Come menzionato in un commento, C ++ non ha una classe come oggetto. C ++ è per molti versi non tipizzati, così i problemi che ho citato sopra non sono applicabili. Inoltre, i modelli C ++ forniscono un sacco di polimorfismo e sono utilizzati per implementare le collezioni.

Answer 2

Credo che le coperte risposta accettata più o meno la domanda originale, ma vorrei completarlo (se posso) un po 'da buttare a (abbastanza informale) un paio di idee per quanto riguarda le questioni secondarie.

Da un punto di vista eredità, nulla impedisce alla gerarchia delle classi di avere più radici. Come è stato sottolineato da altri popoli, C ++, così come molti linguaggi OO fanno espressività non vincolo per una singola classe radice antenato.

Tuttavia, da un digitare teorica punto di vista (ricordiamo che eredità e subtyping non sono la stessa cosa, quindi sono probabilmente uscire dalla cornice della questione principale qui), un singolo " top" supertipo può fare un sacco di senso (a seconda del tipo teoria ovviamente). Per esempio, in OCaml, v'è un supertipo comune a tutti gli oggetti (se istanze di classe, o oggetti immediati), < > scritte per indicare che tipo di oggetto è vuoto, cioè non accetta alcun messaggio. Questo sembra davvero il tipo di oggetto generale più che possiamo definire, dal momento che non siamo in grado di rimuovere qualsiasi cosa da esso per renderlo più generale. Quindi, in questa concezione dei tipi di oggetti, v'è necessariamente un supertipo di tutti gli oggetti.

Per quanto riguarda il duplice dell'oggetto radice, sport Scala una classe denominata Nothing, che stranamente è vuoto, ed è il sottotipo di ogni altre classi. Non può essere istanziato, ma tiene abbastanza utile semantica per implementare la lista vuota, che si chiama Nil, ed è pari a List[Nothing] (come fuori punte nei commenti, è possibile che il programmatore non usare mai direttamente che valore nel maggior parte dei casi, il che rende apparentemente non così utile come è). Nothing potrebbe essere considerato un duale del tipo radice -. chiamato Any in scala, ma questi tipi non solo coprono classi, ma anche primitive tipi, in modo che tutto può essere upcasted a Any, ad esempio

Answer 3

La capacità di definire collezioni che può contenere tipi arbitrari di cose, senza la necessità di definire i metodi diversi per i diversi tipi di cose, è molto utile. Modelli in C ++ rendere possibile per un singolo file sorgente per definire i tipi di raccolta che possono contenere diversi tipi di cose, ma il compilatore dovranno duplicare il codice per ogni diverso tipo di cose nella collezione. Se invece si definisce quasi tutti i tipi nel sistema per derivano da un unico tipo, quindi una collezione che può contenere riferimenti a cose di quel tipo sarà in grado di riferimenti tenere premuto per cose di qualsiasi tipo.

Questo approccio ha un limite, tuttavia, che è che confonde le distinzioni tra valori ed entità. Un riferimento che incapsula un valore identificando un oggetto particolare può essere sostituito con un riferimento a una copia di tale oggetto senza alterare la semantica. Un riferimento che viene utilizzato per identificare un soggetto, tuttavia, non può essere sostituito in tale modo. Sia l'entità stessa sarà qualcosa che non può essere copiata (ad esempio, se rappresenta una connessione a qualcosa nel mondo reale) o l'entità può incapsulare l'insieme di riferimenti che esistono ad esso . Una cosa fondamentale da notare è che gli oggetti si comportano come valori quando o non possono cambiare o solo riferimento esiste per loro, e si comportano come entità quando esistono più riferimenti.

Sfocatura la distinzione tra i valori e gli enti rende difficile per i tipi di raccolta per sapere se devono considerare il loro contenuto come valori o entità; Questo a sua volta limita la capacità delle collezioni di implementare cose come equals o clone in maniera utile. Lingue che fanno una distinzione di tipo / entità più forti possono avere collezioni fare più cose automaticamente di lingue che non, ma le distinzioni aggiungere una certa complessità, che progettisti di linguaggi possono o non possono sensazione è giustificata dai benefici.