Programmazione ad Oggetti... ma non somiglia a.....

di il
24 risposte

24 Risposte - Pagina 2

  • Re: Programmazione ad Oggetti... ma non somiglia a.....

    Sarà un mio limite ma non ho capito quasi nulla di quello che vuoi dire, nè dove vorresti arrivare con le tue considerazioni che mi sembrano alquanto confuse.

    Mi spiace ma è la mia opinione.

  • Re: Programmazione ad Oggetti... ma non somiglia a.....

    14/02/2025 - oregon ha scritto:

    Sarà un mio limite ma non ho capito quasi nulla di quello che vuoi dire, nè dove vorresti arrivare con le tue considerazioni che mi sembrano alquanto confuse.

    Mi spiace ma è la mia opinione.

    Ciao Oregon, ti ringrazio per il tuo interesse ed il fatto che non hai capito niente di quello che ho scritto ci sta tutto ;-)

    Dal numero di messaggi che hai postato fino ad ora, deduco che tu sia un programmatore professionista, al contrario di me e spero anche con molta pazienza.

    Allora riassumo, se ci riesco, il mio pensiero dall'alto della mia ignoranza in materia.

    Ho iniziato a leggere un libro sulla programmazione in C++ che ho trovato in internet che ho abbandonato dopo un po perché l'ho ritenuto poco chiaro e comprensibile, non ricordo il titolo mi dispiace.

    Adesso sto leggendo quello di apogeo educational, C++ fondamenti di programmazione seconda edizione, che ritengo scritto molto bene, in più seguo qualche playlist su youtube, per vedere come la pensano gli altri e come spiegano le cose.

    Il libro della apogeo è scritto molto bene, ma anche qui la spiegazione della Programmazione ad oggetti non è proprio chiarissima, facendo anche ricerche su internet, sempre sullo stesso argomento, ho riscontrato delle spiegazioni altamente contorte.

    Nei post che ho scritto qui ho semplicemente cercato di esprimere le mie opinioni sull'argomento, proprio da persona che si affaccia per la prima volta nell'affrontare questo tipo di argomento.

    Ci sono delle spiegazioni che ho trovato in giro che io ritengo veramente poco chiare e poco intuitive, in alcuni casi penso che stiano scrivendo della roba senza senso.

    Forse è per questo che i miei post risultano poco chiari e confusionari.

    Ora dici tu perché li hai scritti proprio qui ?

    Intanto per raccogliere le mie idee, che come hai ben capito sono poche e confuse, e poi proprio per cercare persone che magari hanno riscontrato lo stesso mio problema e magari in seguito hanno avuto l'illuminazione.

    Cosi magari illuminano anche me.

    Se poi qualche professionista con molta pazienza :-) riesce a farmi capire dove sbaglio e come affrontare meglio questo argomento, ben venga, infondo alla fine è questo che sto cercando un dialogo con persone che ne sanno più di me per imparare da loro.

    Spero di essere stato più chiaro.

  • Re: Programmazione ad Oggetti... ma non somiglia a.....

    15/02/2025 - TonyF ha scritto:

    Se poi qualche professionista con molta pazienza :-) riesce a farmi capire dove sbaglio e come affrontare meglio questo argomento, ben venga, infondo alla fine è questo che sto cercando un dialogo con persone che ne sanno più di me per imparare da loro.

    Per capire dove sbagli, ci deve essere qualcosa da valutare. Io ho riletto il thread ma non si capisce dove si voglia andare a parare: sembra più una serie di considerazioni filosofiche, ma quello che manca è una chiara e precisa enunciazione di un problema e/o di un dubbio a cui dare risposta.

    Si parla di "evoluzione della programmazione", progetti grandi, progetti piccoli, però non è chiaro né qual è il problema né l'obiettivo del thread né dove si vuole arrivare.

    E' vero che siamo tutti molto impegnati, ma nessuno (credo) disdegna una discussione interessante, purché si parli di qualcosa, e in questo contesto - almeno per quanto mi riguarda - non c'è nulla che valga la pena di esprimere un parere o commentare. Chiacchierare si può fare e può essere anche piacevole, ma se si parla del meteo allora la voglia passa, e non è per mancanza di volontà nello scambiare delle chiacchiere, ma perché l'argomento non è interessante, o lo sarebbe ma non si capisce né il contesto né l'obiettivo finale.

  • Re: Programmazione ad Oggetti... ma non somiglia a.....

    Ora più vado avanti e più ho l'impressione che qui si stia parlando di una specie di evoluzione del concetto di subrutine.

    Quasi!

    1) esiste la programmazione PROCEDURALE< dove si usano le SUBROUTINE

    2) poi c'e' la programmazione ad OGGETTI che un'evoluzione della programmazione PROCEdurale, ed in cui ci sono i METODI che sono un'evolcuzione delle SUBROUTINE

    Il concetto di programmazione ad oggetti dovrebbe semplificare la stesura di un programma molto complesso,

    Ni. Diciamo che non centra niente, tanto per semplificare:

    la programmazione AD OGGETTI sta alla programmazione PROCEDURALE

    COME

    un'automobile sta ad una trattore.

    In entrambi i casi puoi fare le stesse cose, MA certe cose si possono fare meglio in un modo e certe altre nell'altro.
    (portare la morosa a mangiare la pizza usando il trattore non e' il massimo, 
    attraversare il letto del torrente per andare nella spiaggetta segreta con la macchina, non e' una genialata ;-) )
    La progrmmazione OOP NON E' MEGLIO, e' SOLO (leggermente) DIVERSA.

    in questi programmi c'era già la possibilità di richiamare programmi esterni da un programma principale per poi fargli eseguire dei calcoli o 

    @oregon, mi sa che 'richiamare programmi esterni', visto gli anni, il linguaggio di programmazione e le conoscenze del nostro amico coinvolti, NON SI RIFERISCE ad un processo esterno come lo immaginiamo oggi, MA PROPRIO ad una SUBROUTINE/FUNZIONE alla "programmazione procedurale" ;-)
    .

    Ora il concetto non era cosi complesso come la programmazione da oggetti, ma ci vedo molte somiglianze.

    E ci sono (QUASI) tutte. il METODO, e' la versione potenziata della SUBROUTINE

    La sostanziale differenza che distingue un linguaggio procedurale da uno OOP è che il linguaggio OOP va incontro ai problemi che si pongono nell'affrontare la stesura di un programma di grosse dimensioni, tipo un OS o roba similare.

    Non centra niente: Linux, che E' un OS, e' scritto in C, quindi usando la programmazione PROCEDURALE.

    Permette la stesura di un prg dividendo il lavoro su più persone in modo più naturale ma soprattutto da la possibilità ad uno o più programmatori di svolgere il proprio lavoro, indifferentemente da cosa stanno facendo un o più altri programmatore, ed ecco le classi o oggetti.

    Neanche questo. La suddivisione di un programma in piu' "moduli" in modo che ogni persona possa lavorare su quel modulo con MINIME interferenze con gli altri moduli/persone NON DIPENDE dal linguaggio di programmazione. 

    Poi' e' ovvio che in qualche modo il linguaggio di programmazione c'entra.
    Ma e' come avere macchinari da taglio che funzionano con il 110V o il 220V: se devi tagliare, la tensione con cui funziona il macchinario NON E' discriminante, a te serve QUEL tipo di macchinario. Poi e' ovvio che se sei negli USA, dovrai usare un macchinario che funziona con il 110V mentre se sei in Italia devi usare uno che va a 220V.

    @dobbi: idea BUONA ma SBAGLIATA.
    DOVEVI fare: TObject->TAnimale ->TCane & TGatto, cosi' mostravi il concetto di EREDITARIETA' E' POLIMORFISMO, i DUE CONCETTI FONDAMENTALI della OOP.

    Ritengo il sistema di programmazione con le classi un sistema super ottimizzato per il riutilizzo del codice, quindi non stare li a riscrivere cento volta la stessa cosa, ma anche per dividere in modo più chiaro un codice complesso, poi ci sono anche altre cose che ancora non ho studiato come l’ereditarietà, che sembrano aiutare ad ottimizzare il codice di molto e permettono la risoluzione di alcuni problemi in modo più semplice e intuitivo.

    Anche questo non centra niente. Il riutilizzo DELLE FUNZIONALITA' (piu' che del codice) NON DIPENDE dal linguaggio di programmazione MA da COME il codice viene organizzato.

    Grazie al UML e la OOD, un progetto di grandi dimensioni, può essere pensato e suddiviso in parti più piccole, cioe come quando si prende un oggetto e lo si scompone nelle sue parti primarie, poi ogni parte avrà un funzione, che a sua volta potrà avere determinate caratteristiche. 

    Ni: UML serve per avere un "linguaggio visuale" per rappresentare come un sistema complesso deve essere scomposto e quale debba essere il suo funzionamento.
    La OOP, di nuovo, non centra niente. Puoi fare le stesse cose in un linguaggio procedurale, funzionale, logico, a regole, ... Insomma: NON CENTRA NIENTE.

    La classi ovviamente si adattano molto efficacemente al sistema di programmazione ad oggetti

    Quasi: il termine "classe", in questo contesto (ne esistono altri in cui "classe" vuol dire altro) E' SINONIMO di programmazione ad oggetti: la OOP SI FA con le classi
    ---

    @oregon non ha pazienza ;-)

    E' ovvio che hai le idee confuse e come risultato fai un polpettone di cose senza senso ;-)

  • Re: Programmazione ad Oggetti... ma non somiglia a.....

    15/02/2025 - TonyF ha scritto:

    Ci sono delle spiegazioni che ho trovato in giro che io ritengo veramente poco chiare e poco intuitive, in alcuni casi penso che stiano scrivendo della roba senza senso.

    15/02/2025 - migliorabile ha scritto:

    Il concetto di programmazione ad oggetti dovrebbe semplificare la stesura di un programma molto complesso,

    Ni. Diciamo che non centra niente, tanto per semplificare:

    Ciao,

    da varie citazioni una breve sintesi e argomenti ... "rimanendo nella semplificazione"

    • Programmazione Procedurale
      • Il programma è organizzato in procedure o funzioni che operano su dati.
      • I dati sono separati dalla logica di elaborazione.
      • L'esecuzione segue un flusso sequenziale e spesso dipende da strutture di controllo come cicli e condizioni.
      • La modularità è ottenuta tramite suddivisione in funzioni, ma il codice può diventare difficile da mantenere con l'aumento della complessità.
    • Programmazione ad Oggetti
      • Il codice è organizzato in oggetti, che sono istanze di classi.
      • Una classe incapsula dati (attributi) e comportamenti (metodi) in un'unica entità.
      • Si basa su quattro principi fondamentali:

    [cit.]

    I quattro principi di base della programmazione orientata agli oggetti sono:

    • Astrazione Modellazione degli attributi e delle interazioni pertinenti delle entità come classi per definire una rappresentazione astratta di un sistema.
    • Incapsulamento Nascondere lo stato interno e la funzionalità di un oggetto e consentire l'accesso solo tramite un set pubblico di funzioni.
    • Ereditarietà Possibilità di creare nuove astrazioni in base alle astrazioni esistenti.
    • Polimorfismo Capacità di implementare proprietà o metodi ereditati in modi diversi tra più astrazioni.

    Differenze:

    CaratteristicaProcedurale : (C, Pascal, Fortran, Cobol, Basic, Clipper,...)ad Oggetti: (C++, Java, C#, VB.NET,...)
    StrutturaFunzioni e dati separatiDati e funzioni uniti in oggetti
    RiutilizzabilitàLimitata, richiede copia del codiceAlta, grazie a ereditarietà e polimorfismo
    ModularitàBasata su funzioniBasata su classi e oggetti
    ManutenzioneDifficile per progetti grandiPiù semplice e scalabile
    Sicurezza dei datiDati globali facilmente accessibiliIncapsulamento protegge i dati

    .

    • Richiamare Programmi Esterni
      • Esempio di Librerie
        • Librerie Standard: librerie predefinite (Standard Library)
        • Librerie di terze parti: possono essere incluse nel progetto
        • Librerie Native del S.O.: esempio.. DLL in Windows (user32.dll, kernel32.dll) etc.
      • Principali Caratteristiche
        • Risparmio di tempo: Non serve reinventare la ruota
        • Affidabilità: Librerie ben testate riducono il rischio di errori
        • Manutenzione facilitata: Se una libreria viene aggiornata, puoi beneficiare delle migliorie senza dover cambiare il tuo codice
        • Prestazioni ottimizzate: Molte librerie sono scritte in modo efficiente per offrire performance migliori

    .
    In questi casi alcune librerie possono essere di tipo Procedurale, ad Oggetti oppure entrambe i tipi.

    .

    Personale consiglio... 

    Puoi iniziare dagli argomenti sopra citati e approfondire il significato dei singoli punti/affermazioni.

    Alla fine di questi approfondimenti probabilmente alcune cose non ti sembreranno ancora chiare del tutto. 

    Questo dipende dalle esperienze e conoscenze in tuo possesso.

    Esempio: per chi ha lavorato con la programmazione fino agli anni '80 (programmazione Procedurale) e successivamente dagli anni '90 in poi (programmazione ad Oggetti), questi concetti sono di facile comprensione e assimilazione. 

    Mentre per chi non ha lavorato con una delle due fasi di programmazione, la parte sconosciuta rimarrà solo una "teoria" che spesso può risultare di difficile comprensione.
    Quindi ci può stare, ed è normale, un pò di confusione e perplessità come da te sottolineate, 

  • Re: Programmazione ad Oggetti... ma non somiglia a.....

    Vediamo se riesco a insegnare la OOP in UN POST.
    Supponiamo che chi legge conosca GIA' la programmazione procedurale ed i concetti base.

    Programmazione Procedurale:

    1. tipi "primitivi":
      1. intero (int),
      2. float,
      3. boolean (vero/falso).
      4. ... C'e' ne sono altri, ma manteniamoci al minimo sindacale
    2. tipi "strutturati": se T e' un tipo (primitivo O strutturato), abbiamo
      • T[n] (array): uno scatolone contenente tante scatollette, identificate da un NUMERO (0,1,2,..) ogn'una contenente SEMPRE lo stesso TIPO di valore. 
        Ad esempio int[5] e' un vettore di 5 interi, float[3][5] e' un vettore BIDIMENSIONALE/MATRICE di numeri con la virgola
      • T1 x T2 x ... (prodotto cartesiano/struttura): e' uno scatolone contenente tante scatolette, identificate da un NOME (ad esempio 'id', 'x' e 'y'), dove ogni scatoletta puo' contenere un tipo di valore diverso. NESSUNO limita il fatto che scatolette diverse possano avere lo stesso tipo di valore.
        Ad esempio  struct { int id, float x, float y }: rappresenta un punto in 2 dimensioni, con un identificativo ("id")
    3. funzioni/procedure: una volta, ed in Pascal questo c'e' ancora (o ci dovrebbe ancora essere) SE avevi una "funzione" che non deve ritornare nulla, la chiamavi "procedura". MA nel 99.9% del funzionamento, funzioni e procedure sono ESATTAMENTE la stessa cosa. 
      In C, una "procedura e' una funzione che ritorna "void", cioe' "niente".
      Ma che cosa e' una "funzione"? 
      e' un pezzetto di codice che ha un NOME, un certo numero di PARAMETRI in ingresso e ritorna un "unico" valore come RISULTATO (che puo' essere anche il valore "speciale" "niente"). Ad esempio:
      1. float sin(float x) la funzione trigonometrica "seno",
      2. int sum(int[] array): la funzione che ritorna la somma di tutti i valori interi all'interno dell'array

    .

    Ora supponiamo di avere un "ostello per animali" in cui teniamo cani e gatti. Ci servono 3 tipi strutturati:

    1. 'Ostello': la struttura contenente l'array di cani e di gatti
    2. 'Cane': la struttura ceh descrive un cane
    3. 'Gatto': la struttura che descrive un gatto.

    .

    Per un motivo 'convenzioni nella scrittura del codice' in MOLTI linguaggi di programmazione, i nomi delle strutture dati iniziano con la lettera maiuscola.

    Ora sevono un po' di funzioniche per gestire il tutto:

    1. Cane creaCane(...): crea un'istanza della struttura Cane con le info sul cane (nome, allergie, proprietario, che cosa mangia)
    2. Gatto creaGatt(...): come sopra ma per un gatto
    3. Ostello creaOstello(): come sompra ma per l'ostello
    4. aggiungiCane(Ostello ostello, Cane cane): aggiungi un cane all'ostello
    5. rimuoviCane(Ostello ostello, Cane cane): rimuovo un cane all'ostello
    6. aggiungiGatto(Ostello ostello, Gatto gatto)
    7. rimuoviGatto(Ostello ostello Gatto gatto)

    .

    Come noti, ci sono UN SACCO di diplicazioni: cose MOOOLTO simili ma che DEVONO essere mantenute diverse. 
    Per esempio: all'ostello non interessa sapere se deve accettare un cane (dal nome Ettore) o un gatto (dal nome SIlvestro): li accetta entrambi, e per entrabi fa ESATTEMENTE le stesse operazioni di registrazione, scelta della gabbia, ricordarsi di dargli da mangiare ad intervalli regolari ...
    Ci sono solo PICCOLE differenze sul fatto che uno sia un cane  el'altro un gatto. Ma sono poche.
    Altro problema: SUPPONIAMO che l'ostello decida di accettare ANCHE Pantere (in particolare di colore Rosa, pensavo ad Uccellini Gialli dal nome Titti, ma Pantere Rosa mi suona meglio ;-))
    Sai che scocciatura dove implementare TUTTA una serie di funzionalita' che sono il copia/incolla al 90% di quello che e' gia' stato scritto?
    .

    E qui entra in gioco la OOP (Object Oriente Programming).

    .

    .

    Programmazione ad Oggetti 1: EREDITARIETA'

    Invece di avere Cane e Gatto (e Pantera :-)) come strutture dati diverse, le componiamo in questo modo

    1. Animale: una struttura dati che contiene TUTTE le informazioni comuni tra cani, gatti e pantere (rosa)
      1. Cane extends Animale: la struttura dati che EREDITA tutti i campi di Animale e che aggiunge quello suoi specifici. Ad esempio il tipo di osso che gli piace masticare
      2. Gatto extends Animale: come sopra. Ad esempio quale animale odia (Titti? :-))
      3. Pantera extends Animale: come sopra, con le sue specifiche caratteristiche (la marca del fucile che predilige quando deve sparare a qualcuno ;-))
        1. qui' servira aggiungere una nuova funzione "Pantera creaPantera(...)", ma ci sta', essendo un oggetto totalmente nuovo

    .

    Gia' in questo modo possiamo semplificare le funzionalita' associate ad Ostello, perche' invece di avere: aggiungiCane, aggiungiGatto, aggiungiPantera, rimuoviCane, ..., bastano

    1. aggiungiAnimale(Ostello ostello, Animle animale)
    2. rimuoviAnimale(Ostello ostello, Animale animale)

    .

     SI e' passati da 6 a 2.
    Non solo, ma diventa "banale" aggiungere altri tipi di "animali", che ne so, una "Puzzola" (dal nome "Pepé Le Pew" ;-)) o "Canarino" (dal nome "Titti" :-) ), ecc.

    .

    .

    Programmazione ad Oggetti 2: POLIMORFISMO

    Al punto 1) abbiamo creato 4 strutture dati:

    1. Animale
      1. Cane extends Animale
      2. Gatto extends Animale
      3. Pantera extends Animale

    .

    Ora, ovviamente ogni 'animale' deve mangiare e ci serve sapere CHE COSA puo' mangiare. E' ovvio che per 'Animale', essendo un animale 'generico' non lo si puo' sapere apriori, MA per 'Cane' sappiamo che mangia "carne", il "Gatto" mangia "pesce" e "Pantera" (sopprattuto se Rosa) mangia "PizzaLuigiXII" (12 MILA dollati al pezzo ;-)).

    Diciamo di assegnare:

    1. il valore intero 1 per "carne"
    2. il valore intero 2 per "pesce"
    3. il valore intero 12000 per "PizzaLuigiXII"

    .

    Ora ci serve una "funzione" che dato un "Animale" mi ritoni "che cosa mangia" in forma di un numeri intero, che nel nostro caso sara' 1, 2, o 12000. 
    La funzione DEVE essere:

    • int cheCosaMangia(Animale animale)

    .

    E' OVVIO che questo non basta, MA ci servono anche una serie di "funzioni" che hanno lo STESSO NOME, ogn'una per un diverso tipo di animale:

    1. int cheCosaMangia(Cane cane) { return 1; }
    2. int cheCosaMangia(Gatto gatto) { return 2; }
    3. int cheCosaMangia(Pantera pantera) { return 12000; }

    ,

    E QUI entra in gioco la vera "potenza" della programmazione OOP: E' RESPONSABILITA' dell'implementazione del linguaggi di programmazione TROVARE UN MODO per decidere SE usare 1), 2) o 3) QUANDO nel codice viene chiamato 

    • int cheCosaMangia(animale)

    .

    SENZA SAPERE che animale e' ESATTAMENTE ma che, DI VOLTA IN VOLTA, l'animale passato puo' essere un cane, un gatto o una pantera "rosa".

    Nota per i puristi 

    questa sintassi e' stata proposta da Stroustrup:

    https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4474.pdf 

    Inoltre e' implementata, in versione generalizzata, in Julia.

    .

    .
    Programmazione ad Oggetti 3: CLASSI & METODI

    Con quanto detto nei punti 1 e 2 abbiamo TUTTO quello che serve per passare alla Programmazione Orientata agli Oggetti (OOP):

    1. una classe non e' altro che una struttura che non ha SOLO i campi contenenti i dati, ma anche APPICCICATE le funzioni per manipolarla.
      Nell'esempio di cui sopra,
      1. Cane ha appiccicato int cheCosaMangia(Cane cane),
      2. Gatto ha appiccicatto int cheCosaMangia(Gatto gatto),
      3. Pantera ha appiccicatto int cheCosaMangia(Pantera pantera),
      4. Animale ha appiccicato int cheCosaMangia(Animale animale)
    2. un metodo non e' altro che le "funzioni" usate sopra ma scritte in modo leggermente diverso:
      1. invece di int cheCosaMangia(Cane cane),
      2. si scrive int Cane.cheCosaMangia()
        come si puo' notare dalla sitassi, e' SPARITO il PRIMO parametro, perche' sara' responsabilita' del compilatore aggiungerlo AUTOMATICAMENTE.

    .

    Quindi, un ipotetico pezzetto di codice in STILE PROCEDURALE:

    Animale animale = creaPantera("Rosa");
    print(cheCosaMangia(animale))

    in stile OOP diventerebbe

    Animale animale = creaPantera("Rosa");
    print(animale.cheCosaMangia());

    .

    Conclusioni

    E' OVVIO che spiegare la OOP in un SINGOLO post e' alquanto arduo (ed e' il primo tentativo, magari con ulteriori raffinamenti si puo' fare di meglio)

    Ed e' anche ovvio che sono stati descritti SOLO i due concetti piu' importanti. 
    Il C++ e' infinitamente piu' elaborato, con un'infinita' di funzionalita' aggiuntive.

    Ma, insomma. ;-)

  • Re: Programmazione ad Oggetti... ma non somiglia a.....

    15/02/2025 - migliorabile ha scritto:

    E' OVVIO che spiegare la OOP in un SINGOLO post e' alquanto arduo

    Confermo!!!  ;-)

    aggiungerei che personalmente a quest'ora del mattino le mie sinapsi ancora stentano a connettersi ;-))

  • Re: Programmazione ad Oggetti... ma non somiglia a.....

    15/02/2025 - Alka ha scritto:

    Per capire dove sbagli, ci deve essere qualcosa da valutare. Io ho riletto il thread ma non si capisce dove si voglia andare a parare: sembra più una serie di considerazioni filosofiche, ma quello che manca è una chiara e precisa enunciazione di un problema e/o di un dubbio a cui dare risposta.

    Concordo totalmente

    15/02/2025 - Alka ha scritto:

    purché si parli di qualcosa

    Esatto

    15/02/2025 - migliorabile ha scritto:

    il METODO, e' la versione potenziata della SUBROUTINE

    Non è proprio così, non sono d'accordo

    15/02/2025 - migliorabile ha scritto:

    @oregon non ha pazienza ;-)

    E' ovvio che hai le idee confuse e come risultato fai un polpettone di cose senza senso ;-)

    Non c'entra (con l'apostrofo @migliorabile) niente la pazienza. Non si può leggere il "polpettone" di cui parli, bisognerebbe rispondere con un intero libro sulla OOP, non un solo post.

    Rispondere riassumendo l'OOP in un post non ha molto senso.

    Quello che l'op deve fare è riprendere i libri e rileggerli, evitando paragoni con la programmazione procedurale/strutturata e affrontando i singoli concetti SENZA volerli paragonare a quelli della programmazione classista.

    L'op deve vedere la OOP come qualcosa da studiare indipendentemente dalle sue altre conoscenze.

    E tornare qui a chiedere specifici problemi, difficoltà su uno specifico argomento su cui si può chiarire. Niente filosofia, niente richieste di avere la conferma di idee che non hanno fondamento.

  • Re: Programmazione ad Oggetti... ma non somiglia a.....

    Buongiorno a tutti.... Vedo che questa mattina siete caduti tutti dal letto... :-)

    Prima di tutto vi ringrazio tutti, grazie infinite per il tempo che mi avete dedicato.

    15/02/2025 - By65Franco ha scritto:

    Personale consiglio... 

    Puoi iniziare dagli argomenti sopra citati e approfondire il significato dei singoli punti/affermazioni.

    Alla fine di questi approfondimenti probabilmente alcune cose non ti sembreranno ancora chiare del tutto. 

    Questo dipende dalle esperienze e conoscenze in tuo possesso.

    Esempio: per chi ha lavorato con la programmazione fino agli anni '80 (programmazione Procedurale) e successivamente dagli anni '90 in poi (programmazione ad Oggetti), questi concetti sono di facile comprensione e assimilazione. 

    Mentre per chi non ha lavorato con una delle due fasi di programmazione, la parte sconosciuta rimarrà solo una "teoria" che spesso può risultare di difficile comprensione.
    Quindi ci può stare, ed è normale, un pò di confusione e perplessità come da te sottolineate, 

    Ho interrotto la programmazione dopo aver lasciato l'amiga e la sto riprendendo adesso dopo praticamente 32 anni, un’era geologica ( porca paletta, ma quanto sono vecchio ????  :-() , quindi il tuo consiglio e il tuo esempio sono preziosissimi, adesso penso di aver capito che stavo ancora ragionando con le logiche di un tempo.

    15/02/2025 - migliorabile ha scritto:


    E' ovvio che hai le idee confuse e come risultato fai un polpettone di cose senza senso ;-)

    Grazie anche a te che ti sei preso la briga di smontare tutti i mie pasticci per districarli un bel po.

    anche questo mi sta aiutando a capire che ho ancora delle convinzioni attaccare troppo al passato e che vanno evolute.

    Mi sono copiato i tuo posto in un pdf e me li sono salvati e stampati, compreso quello di By65Franco.

    Penso che mi saranno veramente utili in futuro come riferimento.

    15/02/2025 - oregon ha scritto:

    Non c'entra (con l'apostrofo @migliorabile) niente la pazienza. Non si può leggere il "polpettone" di cui parli, bisognerebbe rispondere con un intero libro sulla OOP, non un solo post.

    Rispondere riassumendo l'OOP in un post non ha molto senso.

    Quello che l'op deve fare è riprendere i libri e rileggerli, evitando paragoni con la programmazione procedurale/strutturata e affrontando i singoli concetti SENZA volerli paragonare a quelli della programmazione classista.

    L'op deve vedere la OOP come qualcosa da studiare indipendentemente dalle sue altre conoscenze.

    E tornare qui a chiedere specifici problemi, difficoltà su uno specifico argomento su cui si può chiarire. Niente filosofia, niente richieste di avere la conferma di idee che non hanno fondamento.

    Grazie Oregon anche a te, seguirò anche il tuo consiglio, niente più filosofia, ma se non avessi insistito con i miei polpettoni, a quest’ora voi eravate ancora a letto e io sarei rimasto immerso nei mie ragionamenti confusionari.

    Di nuovo grazie a tutti e se vi scappa urgentemente qualche altro consiglio non fatevi pregare...;-)

    Vi auguro un buon fine settimana,ciao

  • Re: Programmazione ad Oggetti... ma non somiglia a.....

    @TonyF, consiglio:

    il C++ e' complesso, anche per chi e' esperto. Lo usi quando ti serve sfruttare tutta la potenza di calcolo dell'hardware che hai a disposizione.

    MA, se vuoi semplicemente giocare a programmare, ti consiglio Python.

    Se lo guardi con occhi semplici, e' un linguaggio molto semplice, 
    MA se lo guardi con 'attenzione', e' un linguaggio che ti permette di esplorare concetti DECISAMENTE sofisticati: dalla programmazione procedurare, alla programmazione ad oggetti, funzionale, alla META programmazione.

    Inoltre e' il linguaggio principe in ambito Intelligenza Artificiale (ChatGPT, Midjourney DALL-E, e compagnia bella).

    Con un PC carrozzato ed una buona scheda grafica, puoi fare, sul  TUO computer, cose DECISAMENTE interessanti in ambito AI.

    E' MENO potente del C++, MA ha un'INFINITA' di librerie gia' pronte per fare di tutto e di piu' (le quali, sotto sotto, sono scritte in Fortran, C, C++) .

Devi accedere o registrarti per scrivere nel forum
24 risposte