Discussione:Programmazione orientata agli oggetti

Da Wikipedia, l'enciclopedia libera.

Monitoraggio voci · (che vuol dire?)
	Questa voce è seguita dal Progetto:Informatica. Se vuoi partecipare, visita il bar tematico. Aiutaci a migliorare questa voce inserendo qui sotto una valutazione qualitativa o aggiornando i dati presenti.  ricarica
Programmazione orientata agli oggetti - cronologia valutazioni - inserisci o modifica i dati n.c. La voce non è ancora stata classificata per qualità. Inserisci un livello qualitativo seguendo questo schema. Fonti assenti La voce non presenta alcuna fonte. Se puoi aggiungi una bibliografia o note nel testo. Vedi qui per approfondimenti. Immagini assenti La voce è totalmente priva di immagini o presenta immagini di bassa qualità. Se puoi, integra la voce con delle immagini a licenza libera. Fondamentale La voce fornisce informazioni fondamentali nell'ambito dell'argomento curato dal Progetto:Informatica. Il tema trattato è considerato indispensabile per poter capire l'argomento generale e fa parte delle conoscenze comunemente considerate basilari in materia. (schema) note:

salve, leggendo il paragrafo: Diversi approcci all'OOP, mi è sembrato sconveniente presentare un piatto di spine dopo le rose e i fiori:) a chi fosse alle prese con un linguaggio a oggetti puro(che tratta anche i tipi primitivi o nativi come oggetti(per es. visualbasic.net)), e invece lodare senz-ombra di dubbio la "praticità" e il "realismo" degli architetti di java... Certo gli architetti java, credono che la gestione di oggetti sia troppo pesante per i tipi di software essenziali quali i tipi di dati elementari. In java quando si dichiara un int si stà creando una variabile che contiene i dati assegnati ad essa ed è memorizzata nello stack, dove viene elaborata in modo più efficiente rispetto all'oggetto medio.

Ebbene molti puristi orientati agli oggetti credono che gli inventori di java abbiano fatto un grave errore non rendendo oggetti i tipi nativi. per cominciare, la miscela di tipi nativi e di oggetti invalida il polimorfismo, perchè non è possibile inserire un tipo primitivo in un campo chiedendo un oggetto: è prima necessarrio convertirlo in oggetto. inoltre i tipi primitivi non possono essere facilmente impiegati in un object model che fornisce capacità runtime type information o di riflessione. Per lavorare con oggetti puri è necessario in primo luogo racchiudere manualmente i valori in pesanti classi wrapper, creando problemi e ostacoli nelle prestazioni... Attualmente i programmatori java devono racchiudere un int ogniqualvolta sia neccessario nel regno degli oggetti. Per questo un grande insieme in java stà facendo pressioni sui creatori per fare in modo che implementino classi leggere e convertano le primitive in oggetti, rendeno così java orientato agli oggetti al 100%...

--Lorenzos 00:44, Set 10, 2005 (CEST)

Sono d'accordo. Ho cambiato il titolo in "Problemi dei linguaggi OOP" che mi sembra più adatto.

--Utente:gcorriga

Credo ci sia un errore nella parte sull'ereditarietà. Una sottoclasse non è necessariamente un sottotipo, anche se può esserlo, perché in effetti è possibile per una classe non rispettare le precondizioni fornite dalle classi genitrici.

Per me poi la prima parte su "problemi dei linguaggi OO" andrebbe eliminata, linguaggi completamente statici (nel senso di compilazione AOT non JIT) come Eiffel hanno prestazioni equivalenti a quelle del C pur non avendo nessuna "tipo base", in quanto è banale effettuare la trasformazine in tipi nativi a compile time, e le tecniche per ottenere certi risultati sono vecchie decenni. --Utente:riffraff

Non vorrei sbagliare completamente, ma mi lascia perplesso la parte sul binding dinamico. Di binding dinamico ne esistono molti tipi, e quello di java e c++ (comportamento polimorfico) segue sì la definizione, ma il nome è associato comunque a compile-time ad un insieme limitato di funzioni e non richiede un grande sforzo da parte del compilatore.Il tipo di dati, la signature, etc... sono già conosciuti. Andrebbe forse citato il binding "completamente dinamico" dove non è non a priori 1)Il tipo di dato del simbolo 2) L'esistenza del simbolo 3) se il simbolo è una funzione, i suoi parametri. In quel caso il bind si effettua totalmente a runtime e richiede uno sforzo maggiore da parte dell'interprete / libreria di runtime . mi riferisco ad esempio, ai linguaggi di scripting, o VB, etc... Che ne pensate? Scusate per i termini eventualmente errati --Utente:QbProg