Discussione:Programmazione orientata agli oggetti

	Questa voce rientra tra gli argomenti trattati dal progetto tematico sottoindicato. Puoi consultare le discussioni in corso, aprirne una nuova o segnalarne una avviata qui.
Informatica bar di progetto monitoraggio voci

La voce è stata parzialmente monitorata, completa la valutazione.

nc Nessuna informazione sull'accuratezza dei contenuti. (che significa?) nc Nessuna informazione sulla scrittura. (che significa?) D Gravi problemi relativi alla verificabilità della voce. Molti aspetti del tema sono completamente privi di fonti attendibili a supporto. Presenza o necessità del template {{F}}. (che significa?) D Gravi problemi relativi alla dotazione di immagini e altri supporti grafici nella voce. Mancano molti file importanti per la comprensione del tema, alcuni essenziali. (che significa?)

Programmazione orientata agli oggetti
Argomento di scuola secondaria di II grado
Materia	informatica
Dettagli
Dimensione della voce	22 528 byte
Progetto Wikipedia e scuola italiana

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

Ma vi pare questo il modo di esprimersi? In questo canale c'è gente che cerca di imparare qualcosa. Chi si erge al ruolo di "professorino" dovrebbe non solo conoscere l'argomento, ma conoscere anche un minimo di italiano, se no non si capisce niente. cito:

"Il concetto di classe può essere considerato l'erede del tipo di dato astratto, una tendenza che si è sviluppata all'interno del paradigma della programmazione procedurale, secondo la quale un modulo dovrebbe implementare un tipo di dato definito dall'utente, con cui si possa interagire solo attraverso una interfaccia ben definita, che nasconda agli altri moduli i dettagli dell'implementazione, in modo che sia possibile modificarli contenendo gli effetti della modifica sul resto del programma."

Chi dovesse leggere questa frase non ci capirebbe niente. Le virgole in italiano esistono per dare delle giuste pause nel discorso ed introdurre una frase subordinata. Credete che per rendere più comprensibile una frase di QUATTRO RIGHE basti mettere a casaccio una virgola qui e una li?

Utilizzo del self in Python

Non credo sia molto preciso dire che si usa self in Python, è solo una convenzione. Potrei benissimo usare Pippo allo stesso modo. --79.19.33.105 (msg) 10:04, 6 ott 2012 (CEST)

Mi fa ridere scrivere qui sotto dopo così tanto tempo, però self non è una convenzione, se al posto di self usassi Pippo non funzionerebbe affatto.

self sta a sostituire il nome dell'oggetto all'interno di una funzione d'istanza, e non è rimpiazzabile con una parola a caso. --FLAK-ZOSO (msg) 15:02, 17 giu 2021 (CEST)