c++, classi e oggetti

[fale]

sto leggendo il libro c++ di Shidth... e non ho capito una cosa... perchè usare le classi e gli oggetti??

nel senso:
le funzioni hanno molti vantaggi (decentralizzazione del sw, riutilizzabilità etc)... gli oggetti???


spero di essere stato chiarto, anche se non penso... perchè manco io ho le idee chiare sull'argomento :cry:

grazie a tutti coloro che mi risponderanno

[jappilas]

sto leggendo il libro c++ di Shidth... e non ho capito una cosa... perchè usare le classi e gli oggetti??

nel senso:
le funzioni hanno molti vantaggi (decentralizzazione del sw, riutilizzabilità etc)... gli oggetti???


spero di essere stato chiarto, anche se non penso... perchè manco io ho le idee chiare sull'argomento :cry:

grazie a tutti coloro che mi risponderannoper prima cosa ci si chieda... cos'è un realtà oggetto? un ' entità in cui chi progetta il SW, "condensa" dei campi dati che, pur vari e tra loro magari eterogenei, ne formano una rappresentazione completa (cioè i campi e i valori contenuti sono tutti quelli necessari a lavorare sul tipo di entità che rappresentano) e che a loro volta avranno bisogno di funzioni dedicate alla loro manipolazione - si ha quindi che la progettazione del sw prevederà di classificare le entità coinvolte, tipizzandole e identificandone le caratteristiche, nonchè le "responsabilità" (*)

detta in questo modo per facilitare la comprensione a chi provenga da linguaggi e paradigmi eclusivamente procedurali , perchè in effetti si può applicare il paradigma a oggetti anche programmando in C , progettando adeguatamente strutture dati e funzioni

ma in realtà una delle caratteristiche principali della programmazione a oggetti, anche se plausibilmente ostica da acquisire e padroneggiare all' inizio, prevede l' aggregazione, ai dati, delle funzioni che li manipolano (che diventano metodi di classe ): questo è detto incapsulazione(*) ed è importante per vari motivi:
da una parte la possibilità di limitare la visibilità dei dati membro, e quindi contingentarne l' accesso al codice esterno alla classe - ah per inciso, è buona norma limitare al minimo indispensabile i dati di classe con visibilità "pubblica", e prevedere piuttosto un metodo di modifica e uno di recupero;
dall' altra, rende disponibile il riuso del codice: altre classi possono riutilizzare i metodi implementate dalla prima, eventualmente in aggiunta a metodi propri, dichiarandosi sue "parenti" ( cioè "figlie", da cui il meccanismo noto come ereditarietà: nel senso concreto del termine, visto che le classi "figlie" ereditano -genericamente, poi ci sono delle considerazioni da fare- i dati e i metodi della classe "genitore")
inoltre, soprattutto quando si ha a che fare con classi già realizzate da sfruttare in un proprio progetto, rende apparente il modello in cui entità discrete (gli oggetti) comunicano tra loro tramite attraverso messaggi scambiati attraverso le loro interfaccie : è importante notare questo, perchè può capitare spesso e volentieri, di concentrarsi solo sullo sfruttamento corretto dell' interfaccia (in pratica, chiamata ai metodi della classe) ignorando l' implementazione e le strutture dati che la classe contiene (oggetti come "scatole nere")

[PGI-Bis]

Mi esercito in un'azzardata divinazione ma io credo che quando fale legga le frasi dove modularità, riuso e incapsulamento diventano grandiose conquiste dell'orientamento agli oggetti egli pensi tra sè e sè "ma io questa roba già la faccio in C, che è procedurale".

Se così fosse allora avrei la conferma di una mia personalissima teoria: ciò che oggi chiamiamo orientamento agli oggetti è una massi indistinta di paroloni tutti riferiti a scarti di produzione di quella che era l'idea originaria di oggetto. Molto curiosamente noi abbiamo perso nel tempo la parte significativa e comprensibile di quell'idea e ci siamo concentrati sulla porzione insignificante e afflitta da numerosi errori genetici (in primis i concetti di classe ed ereditarietà).

[fale]

Quindi sono solo un evoluzioni delle funzioni (con i principi fondamentali sviluppati e il nuovo principio dell'ereditarietà?

@PGI-Bis: +o- 'ho pensato ;)

[vizzz]

Quindi sono solo un evoluzioni delle funzioni (con i principi fondamentali sviluppati e il nuovo principio dell'ereditarietà?

@PGI-Bis: +o- 'ho pensato ;)
pensala di più come all'evoluzione delle struct (almeno io la vedo così)

[TheKaneB]

sto leggendo il libro c++ di Shidth... e non ho capito una cosa... perchè usare le classi e gli oggetti??

nel senso:
le funzioni hanno molti vantaggi (decentralizzazione del sw, riutilizzabilità etc)... gli oggetti???


spero di essere stato chiarto, anche se non penso... perchè manco io ho le idee chiare sull'argomento :cry:

grazie a tutti coloro che mi risponderanno


pensala di più come all'evoluzione delle struct (almeno io la vedo così)

si in effetti la definizione "brutale" che viene più semplice da comprendere è quella della struct (RECORD per chi programma in pascal) + le funzioni (che dentro l'oggetto prendono il nome di methods o metodi)...

Ovviamente è qualcosa di più sofisticato di una struct+funzioni, però rende l'idea...