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

di il
24 risposte

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

Un saluto a tutti gli utenti del forum,

una curiosità, sto leggendo un libro sulla programmazione C++, ora questo linguaggio supporta la cosiddetta programmazione ad aggetti.

In questo momento sto leggendo nello specifico proprio la programmazione ad oggetti, cos’è e come funziona.

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

Quindi volevo una vostra opinione, è solo una mia impressione o è proprio cosi ?

Io mi occupo di produzione elettronica e mi diverto nel tempo libero a capire i meccanismi di funzionamento di alcuni programmi e come vengono sviluppati, questo mi viene utile nel mio lavoro per capire meglio il funzionamento di alcuni sistemi elettronici.

Ciao e buona serata.

24 Risposte

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

    No.

    Una subroutine è più una funzione che un oggetto.

    Nasce con quel codice e al suo richiamo sarà sempre quel codice ad essere eseguito.

    Un oggetto ha metodi, eventi e proprietà.

    Ogni oggetto è indipendente ed esegue il codice allo scatenare dell'evento, la funzione si esegue se viene richiamata.

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

    Ciao sihsandrea e grazie per la risposta.

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

    Il tutto utilizzando il sistema di classi (C++).

    Ma mi ricordo che quando ero ragazzo, mi divertivo con il Visual Basic e l'AMOS ( in pratica il VB per Amiga )

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

    fare in modo di richiamare un modulo di inserimento dati, per poi riportare il risultato di nuovo al programma principale.

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

    "Nasce con quel codice e al suo richiamo sarà sempre quel codice ad essere eseguito."

    Che intendi con questa frase ? anche una classe nasce in quel modo e sarà sempre quel codice che verrà richiamato, o mi sono perso qualcosa per strada !!!!

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

    Ti consiglio di rivedere i concetti della OOP perchè quello che hai scritto circa le subroutine non c'entra quasi nulla.

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

    Ciao oregon grazie tante per la risposta.

    Si credo tu abbia ragione, la tecnica di richiamo di un programma esterno non si può definire proprio una subroutine, ma il concetto base di funzionamento non

    lo vedo molto dissimile dal sistema a classi, anche se molto più rudimentale ovviamente.

    Infatti, come già detto, mi sembra una "evoluzione" molto sofisticata di questo sistema.

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

    12/02/2025 - TonyF ha scritto:

    Nasce con quel codice e al suo richiamo sarà sempre quel codice ad essere eseguito."

    Supponiamo di avere tre pulsanti

    Pulsantecalcolatotalearrotondastandard

    Variabilenumero=1.235

    Arrotonda bla bla

    Variabile diventa 1.24

    Pulsantearrotondaunitasup

    Variabilenumero=1,235

    Arrotonda bla bla

    Variabile diventa 2

    Pulsantearrotondaunitainf

    Variabilenumero=1.234

    Arrotonda bla bla

    Variabile diventa 1

    Per evitare di scrivere tre volte un codice simile creiamo la routine

    Funzionearrotonda(numero: integer; opzione: char)integer

    Bla bla...

    Opzioni: a standard; s: unità superiore; i: unità inferiore

    La richiami così 

    Variabilenumero=funzionearrotondamento(1.235; a)

    Oppure 

    Variabilenumero=funzionearrotondamento(1.235; s)

    Oppure

    Variabilenumero=funzionearrotondamento(1.235; i)

    Questo per la subroutine.

    Per il programma esterno:

    Non è una subroutine ma un programma.

    Lo.rsegui e lui parte e fa qualcosa. Posso avviare la calcolatrice... Paint... Ecc...

    Un oggetto: 

    Prendo un dataset...

    Evento ondatachange

    Scrivo qualcosa....

    Eseguo un refresh

    A) il record è sempre quello l'evento non si scatena e il codice non viene eseguito

    Se chiami la funzione o un programma esterno quello viene eseguito.

    B) cambia il record...

    Viene scatenato l'evento datachange fa qualcosa...

    Hai chiesto la differenza tra subroutine e oggetto.

    L'oggetto (o un programma esterno) anche se contiene codice non si tratta di una routine, un codice che altrimenti sarebbe ripetuto n volte nel listato.

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

    Poi per gli oggetti c'è altro ancora che scoprirai man mano che li studierai

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

    Infatti hai perfettamente ragione sihsandrea,

    Ho chiamato subroutine, un programma esterno, infatti ho cercato di spiegarmi meglio in un post sopra.

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

    Forse non mi ero spiegato bene  prima.

    La programmazione ad oggetti e i suoi principi non hanno nessuna attinenza con l'uso di subroutine o programmi esterni tipici della programmazione classica.

    Certi paragoni ti possono confondere, evita di farli e studia la OOP senza fare riferimenti alla programmazione classica finché non ne avrai appreso bene il funzionamento.

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

    13/02/2025 - oregon ha scritto:

    Forse non mi ero spiegato bene  prima.

    La programmazione ad oggetti e i suoi principi non hanno nessuna attinenza con l'uso di subroutine o programmi esterni tipici della programmazione classica.

    Certi paragoni ti possono confondere, evita di farli e studia la OOP senza fare riferimenti alla programmazione classica finché non ne avrai appreso bene il funzionamento.

    Ciao Oregon, grazie tante per il tuo chiarimento, 

    ho letto piu di un libro che parla di OOP, Classi o Oggetti, etc,etc e ho capito questo :

    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.

    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.

    Il tutto seguendo il metodo UML, OOAD, in questo modo, prima vengono analizzate tutte le parti del programma, cosa deve fare, come, che tipo di dati deve elaborare, come li deve elaborare e quando, questo tipo di approccio poi dividerà l'intero progetto in blocchi più piccoli e facili da gestire, in teoria :-)

    Ovviamente ho tralasciato la parte prettamente tecnica, cioè di come effettivamente si programma con un linguaggio OOP, le varie tecniche, etc, che differiscono dal classico sistema procedurale, ovviamente un linguaggio di programmazione orientato agli oggetti è strutturato per forza di cose, in modo differente da un linguaggio classico procedurale, quindi anche il modo di pensare e programmare ovviamente varia.

    Un esempio che potrei fare è tra il c e il c++ o il c#.

    Questo ovviamente a grandi linee, spero di averci capito qualche cosa :-)

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

    12/02/2025 - TonyF ha scritto:

    una curiosità, sto leggendo un libro sulla programmazione C++, ora questo linguaggio supporta la cosiddetta programmazione ad aggetti

    Ciao,

    la differenza c'è ovviamente ... e per fare un semplice esempio puoi vedere 

    https://learn.microsoft.com/it-it/dotnet/csharp/fundamentals/tutorials/oop

    e   quindi ...

    https://learn.microsoft.com/it-it/dotnet/csharp/programming-guide/classes-and-structs/methods

    A partire da questi due articoli già puoi farti una idea generica e basica.

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

    Grazie By65Franco, gli darò un’occhiata sicuramente.

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

    Ciao tutti,

    Ragazzi so che molti di voi non hanno tempo da perdere, specialmente con uno come me che ama chiacchierare tanto :-)

    Considerano questo sito un posto pieno di professionisti, ma speravo di non trovare solo gente impegnata a sgobbare e basta.

    Adesso spero di non offendere nessuno e parlo sul serio, veramente, è solo un esprimere una personale opinione.

    Ma un sito dove si parla di programmazione anche in modo leggero, giusto quattro chiacchiere tra amici, non c'è ?

    Ho scritto nella sezione Bar di questo sito appositamente, ma sembra che l'argomento sia stato preso troppo seriamente.

    Uno scambio di opinioni e non solo un "meglio che studi ancora" sarebbe stato più gradito.

    Ma io sono uno di quelli che preferisce chiacchierare d'avanti ad una birra di argomenti seri ma in modo easy e non solo leggere libri e basta,

    anche perché era propri dei libri che ho letto che volevo parlare, che secondo me enfatizzano questo argomento in modo esagerato, quasi tutti.

    Sara per il fatto che provengo da un’altra epoca, quella del VIC 20 e del C64, per non parlare di Amiga, ma molti di voi sono giovani e non sanno

    di cosa sto parlando, ed è giusto cosi, il vecchietto che si deve adattare sono io e non di certo voi.

    Di nuovo chiedo scusa a tutti, ma era un discorso buttato li, come di dice.. generico e leggero il mio, ma ho riscontrato questo tipo di approccio in vari forum, quindi forse sono io che devo riflettere un po di più e magari cambiare chissà :-) 

    Di nuovo ciao e grazie di nuovo a tutti.

    TonyF

    P.S.

    Dite a quel tipo che fa il figo sul palco di San Remo che mi deve pagare i diritti d'autore sul nome..... ci sono prima io di lui e già da un bel po.... ;-)

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

    Premesso che non sono programmatore e ad oggetti sono ancora meno capace, da quanto ho capito…

     Come dici la programmazione ad oggetti è un evoluzione di quella classica. Facciamo un esempio, uso per comodità il pascal ( anche se tu studi il c++, al momento non lo uso da tempo)

    Type TCane = Record
           Nome : String;
           Peso : Integer;
           Colore : String;
         End;
    
    Var Uno,Due,Tre : TCane;
    
    Procedure StampaNome(Dati:TCane);
    Begin
      Writeln(Dati.Nome);
    End;
    
    begin
      Uno.Nome := 'Nome';
      Uno.Peso := 100;
      Uno.Colore := 'Giallo';
      Due.Nome := 'Nome1';
      Due.Peso := 100;
      Due.Colore := 'Giallo1';
    
      StampaNome(Uno);
      StampaNome(Due);
    end.

    E cosi non è che non vada bene, è solo che è tutto molto slegato tra di loro, ad oggetti avresti un legame tra dati e codice. Negli oggetti puoi definire anche cosa è usabile solo ad uso interno e cosa è visibile anche dall’utente.

    L’esempio precedente ad oggetti diventerebbe una cosa simile

    program Project1;
    
    Type TCane = Object
           Nome : String;
           Peso : Integer;
           Colore : String;
           Procedure StampaNome;
         End;
    
    Var Uno,Due : TCane;
    
    Procedure TCane.StampaNome;
    Begin
      Writeln(Nome);
    End;
    
    begin
      Uno.Nome := 'Nome';
      Uno.Peso := 100;
      Uno.Colore := 'Giallo';
      Due.Nome := 'Nome1';
      Due.Peso := 100;
      Due.Colore := 'Giallo1';
      Uno.StampaNome;
      Due.StampaNome;
    end.

    I dati del cane sono legati all’oggetto e quindi quando stampo non ho bisogno di passare il parametro.

    Sintatticamente è corretto, ma il primo “errore” che mi viene in mente è che avrei dovuto creare una classe base “animale”dalla quale poi derivare una classe “cane”. 
    Tutti gli animali hanno un peso e un colore, magari non il nome.

    Type
         TAnimale = Object
           Peso : Integer;
           Colore : String;
         End;
    
         TCane = Object(TAnimale)
           Nome : String;
           Procedure Stampa;
         End;
    
    Var Uno,Due : TCane;
    
    Procedure TCane.Stampa;
    Begin
      Writeln(Nome);
      Writeln(Colore);
    End;
    
    begin
      Uno.Nome := 'Nome';
      Uno.Peso := 100;
      Uno.Colore := 'Giallo';
      Due.Nome := 'Nome1';
      Due.Peso := 100;
      Due.Colore := 'Giallo1';
      Uno.Stampa;
      Due.Stampa;
    end.
    

    In questo modo posso creare classi derivate da quella base senza dover duplicare codice.
    Da non programmatore ho capito cosi.

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

    "...Come dici la programmazione ad oggetti è un evoluzione di quella classica...."

    Ciao Dobby,

    Grazie per la risposta e gli esempi che hai postato che sono abbastanza chiari, anche se non conosco il Pascal, sono più che comprensibili.

    I tuoi semplici esempi provano, secondo me ovviamente, che le classi sono una evoluzione della programmazione procedurale, ma non la programmazione ad oggetti, infatti grazie alle classi, una volta che ti sei fatto le tue varie routines per vari scopi, a meno che non le vuoi migliorare o cambiare per qualche motivo, sono li belle e pronte da riutilizzare in modo nettamente più facile e naturale di come si faceva una volta con la classica programmazione procedurale.

    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.

    So che può sembrare confusionario quello che sto cercando di dire, ma la programmazione ad oggetti, viene presentata come una cosa con la quale puoi portare tutto quello che ti circonda in un PC tramite un linguaggio di programmazione che supporti le classi, ma questo è impossibile, non si può fare.

    Al massimo puoi portare la logica per descrivere gli oggetti reali nella programmazione, questo si.

    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. 

    Quindi una volta, diciamo cosi ridotto ai minimi termini un problema complesso, le varie parti che lo compongono possono essere assegnate a team di sviluppo separati, quindi con questo metodo si può innalzare ad altissimo livello la realizzazione di un programma, infatti qui la parola "Oggetto" ha il suo perché.

    Grazie a questi due chiamiamoli pseudo linguaggi, possiamo affrontare e poi realizzare la stesura anche di un grossissimo e complesso programma in modo molto più naturale.

    La classi ovviamente si adattano molto efficacemente al sistema di programmazione ad oggetti, ma non per questo bisogna per forza conoscere UML o OOD per poter usare le classi e realizzare un programma in C++, quando quest’ultimo magari non è troppo complesso.

    Probabile comunque che qualche concetto sulla programmazione ad oggetti, andando avanti con lo studio si schiarirà nella mia mente attualmente cosi confusa :-)))))

    Vediamo comunque se c'è qualche altro megalomane fuori di testa che la pensa come me, hahahah!!!!

    Mi sono dilungato troppo, sorry :-)

Devi accedere o registrarti per scrivere nel forum
24 risposte