Perché esistono in OOP le visibilità?

di il
5 risposte

Perché esistono in OOP le visibilità?

Ciao a tutti
La mia domanda è da ignorante, ed è da uno che non ha una visione molto ampia della programmazione. Lo ammetto. In più ammetto che se una cosa esiste, un perché c'è! Il fatto che io non lo veda mi porta a chiederlo a voi.

Al di là dell'aver capito l'utilizzo di public, private, protected, le visibilità in generale, e anche le estensioni delle classi... mi viene da chiedere perché esistono effettivamente?
Nel senso... dichiaro una variabile private, perché non voglio che venga vista e modificata al di fuori della classe. Ok!
Ma se sono io a programmare, e la dichiarassi public e in nessuna parte del programma la modificassi, perché dichiararla private se non ho intenzione di modificarla? Ma se anche la dichiarassi private e non avessi comunque intenzione di modificarla, perché private?
Mi viene da chiedere: "C'è il rischio che il programma la modifichi a mia insaputa e per evitare il rischio la dichiaro private?"

Stessa cosa per le estensioni. Perché esistono? Perché ho una classe A e dovrei creare classe B per estendere A invece che mettere tutto in A?

Non capisco in quali contesti si possa avere la necessità di estendere una classe invece che inserire tutto in una.
È per una questione di ordine, di leggibilità?

Anche il fatto di creare una classe astratta e per utilizzarla ne devo creare una per poterla estendere. Che senso ha?
Non si può direttamente creare la classe normalmente invece che definirla astratta?

L'unico perché che mi viene in mente è ad esempio se un gruppo di persone lavorano ad un progetto insieme e tutti hanno da gestire solamente una parte di codice e tutti hanno una parte di codice in comune...


Grazie

5 Risposte

  • Re: Perché esistono in OOP le visibilità?

    Premetto che la mi è una risposta da autodidatta, quindi spero in qualche utente più navigato che possa avallare o correggere quanto dirò.

    melixo ha scritto:


    ...Ma se sono io a programmare...
    Il concetto di serve anche a gestire queste problematiche. Fintanto che scriviamo un programma fine a se stesso, a nostro esclusivo uso e consumo, una variabile può avere un qualsiasi livello di visibilità (anche se son pieni i forum di utenti che dichiarano le variabili globali in VBA e poi non capiscono più in quale parte del codice questa prende un valore incomprensibile).
    Se ne modifico il valore (in linea teorica) so cosa sto facendo. Se invece il mio obiettivo fosse quello di sviluppare un DLL? Il valore di una certa variabile dovrebbe rispettare i canoni che io impongo perché so come quella variabile dovrà essere usata negli algoritmi che implemento. Se io avessi una parte di memoria dedicata all'istanza dell'oggetto creato, che è liberamente modificabile, come posso essere sicuro che i valori che verranno assegnati rispettino quelli che sono i requisiti necessari)? Se per dei calcoli mi serve l'accelerazione gravitazionale, e qualcuno potesse modificarne il valore, buona pace ai risultati finali...
    Solo dichiarandola private (quindi proteggendola) e scrivendo i relativi metodi getter e setter (per modificarla o leggerla esattamente in "sicurezza").

    melixo ha scritto:


    Non capisco in quali contesti si possa avere la necessità di estendere una classe invece che inserire tutto in una.
    Immagina di sviluppare un programma che gestisca dei veicoli. Dovresti scrivere una classe per le auto, una per i furgoni, una per le moto... E così via comprendendo magari motoslitte e biciclette.
    Se ad un momento dello sviluppo, ti accorgi che serve, per ogni veicolo, sapere quanti posti a sedere ci sono, e questa proprietà non l'avevi implementata prima? Devi necessariamente riprendere in mano i file che definiscono la classe ed aggiungere in ciascuno il riferimento alla nuova proprietà (intesa come campo private più i metodi getter e setter). Se sfrutti questo non è più necessario, dato che ti basta modificare la classe base per ripercuotere la modifica su tutte le sottoclassi. Questo meccanismo inoltre ti permette di programmare "per differenze". Tutto quello che si ripete lo implemento (e lo testo) una volta sola, mentre quello che cambia da una classe all'altra lo sviluppo separatamente. Se nel riscrivere il codice, sbaglio il copia/incolla da una classe all'altra, sai quanto ci va a trovare il bug? (Già fatto... un bagno di sangue )

    melixo ha scritto:


    Anche il fatto di creare una classe astratta e per utilizzarla ne devo creare una per poterla estendere. Che senso ha?
    In questo caso, l'esempio più calzante che mi viene in mente è quello delle figure geometriche. Tutte avranno un modo per calcolare area e perimetro, ma ciascuna avrà la sua formula matematica per farlo. Se le volessi organizzare in una collezione (perché magari fanno parte di una figura complessa che tu hai scomposto in figure più semplici e il tuo obiettivo fosse quello di calcolare l'area della figura complessa), ti basterebbe creare una lista di Figure, su ciascuna richiamare il metodo Area() e sommare. La classe astratta di base ti permette di dichiarare la collezione e richiamare il metodo, ma la classe derivata che implementa effettivamente il metodo, sarà quella che restituirà il valore. Potrai però essere sicuro che il metodo Figura.Area() sarà implementato e restituirà un dato coerente con quanto atteso
  • Re: Perché esistono in OOP le visibilità?

    melixo ha scritto:


    Al di là dell'aver capito l'utilizzo di public, private, protected, le visibilità in generale, e anche le estensioni delle classi... mi viene da chiedere perché esistono effettivamente?
    Esistono per poter essere applicate, altrimenti direi che non ci hai capito nulla.

    melixo ha scritto:


    Ma se sono io a programmare, e la dichiarassi public e in nessuna parte del programma la modificassi, perché dichiararla private se non ho intenzione di modificarla? Ma se anche la dichiarassi private e non avessi comunque intenzione di modificarla, perché private?
    E se una variabile si chiamasse "Cliente" e io ci metto il nome di un "Fornitore", perché dovrei chiamarla invece "Fornitore" se io so che ci ho messo dentro un cliente? Del resto, io lo so, quindi sarebbe lo stesso, no?

    A parte il fatto che tu stia uno sviluppatore individuale, ciò non significa che non userai mai software scritto da terzi, né che la tua memoria a distanza di mesi non vacilli, ma tralasciando questo fattore le visibilità servono per applicarle alle architetture in modo da garantire che ciò che si è voluto rendere privato e/o pubblico lo sia senza possibilità di errore.

    melixo ha scritto:


    Mi viene da chiedere: "C'è il rischio che il programma la modifichi a mia insaputa e per evitare il rischio la dichiaro private?"
    Il programma lo scrivi tu: è il tuo codice che deve rispettare le regole che tu stesso hai imposto per poter essere compilato.
    A qualcosa di "privato" si può opzionalmente arrivare anche tramite Reflection e con altri meccanismi: non è un sistema di protezione o di sicurezza, ma un sistema architetturale.

    melixo ha scritto:


    Stessa cosa per le estensioni. Perché esistono? Perché ho una classe A e dovrei creare classe B per estendere A invece che mettere tutto in A?
    Nessun motivo, infatti il tuo esempio è sbagliato. Non devi mettere tutto in A o tutto in B, oppure tutto in C, ma hai la possibilità di "derivare" da A mettendo in essa ciò che è comune in B e in C (se ha senso farlo, ovviamente).

    melixo ha scritto:


    Non capisco in quali contesti si possa avere la necessità di estendere una classe invece che inserire tutto in una.
    Se è possibile individuare tra diverse classi un fattore comune, devi piuttosto chiederti perché negarsi il vantaggio di scrivere quel codice una volta sola.

    melixo ha scritto:


    È per una questione di ordine, di leggibilità?
    Serve per evitare duplicazioni inutili del codice, serve per semplificare l'individuazione di un bug e impedire di replicarlo ovunque, serve per imbastire una architettura solida sulla quale sviluppare i successivi pezzi di software.

    melixo ha scritto:


    Anche il fatto di creare una classe astratta e per utilizzarla ne devo creare una per poterla estendere. Che senso ha?
    Non si può direttamente creare la classe normalmente invece che definirla astratta?
    E' inutile chiedersi quanto può essere utile un rastrello ipotizzando lo scenario in cui devi spazzare in casa: si può fare tutto quello che dici, ma ti stai chiedendo l'utilità di una cosa in un contesto dove quella non è necessaria.

    Fossi in te, rileggerei tutto e cercherei qualche esempio anche online per comprendere meglio magari con un approfondimento i concetti che dici di aver compreso ma dei quali continui a proporre gli unici scenari in cui non sono utili, o vederli come obbligo piuttosto che come opportunità.
  • Re: Perché esistono in OOP le visibilità?

    Beh è partito tutto infatti dalla mia premessa che se un qualcosa esiste, un motivo c'è. Solo che io non lo vedevo, perché probabilmente come dici tu non ho avuto modo di vedere esempi, o meglio ancora di sviluppare dei progetti in cui rendermi conto del perché un qualcosa esiste e come risolve dei problemi. Ero io che non vedevo, non che credevo fossero superflui.
    Grazie comunque
    Ringrazio anche Sgrubak che senza farmi esempi di codice mi hai fatto capire meglio il perché della loro esistenza e ho apprezzo molto la risposta.
    Grazie
  • Re: Perché esistono in OOP le visibilità?

    melixo ha scritto:


    Beh è partito tutto infatti dalla mia premessa che se un qualcosa esiste, un motivo c'è. Solo che io non lo vedevo, perché probabilmente come dici tu non ho avuto modo di vedere esempi, o meglio ancora di sviluppare dei progetti in cui rendermi conto del perché un qualcosa esiste e come risolve dei problemi. Ero io che non vedevo, non che credevo fossero superflui.
    No, quello che dicevo io era un'altra cosa, ossia che mi apparivano strani i tuoi esempi in quanto sono certo che non siano quelli usati nella documentazione che hai studiato per spiegare i concetti, quindi il problema non sono negli "esempi sbagliati", ma nella parziale comprensione di quello che è stato spiegato. Per questo, dicevo, forse sarebbe bastato rileggere.

    melixo ha scritto:


    Ringrazio anche Sgrubak che senza farmi esempi di codice mi hai fatto capire meglio il perché della loro esistenza e ho apprezzo molto la risposta.
    Per ricollegarmi a quanto scritto sopra, l'esempio delle figure geometriche è forse quello più ricorrente che viene fatto per spiegare la programmazione a oggetti: è impossibile che, nell'ottica di approfondire questo concetto, cercando in giro non vi fossero esempi che dessero immediata risposta ai tuoi dubbi.

    Comunque, tutto è bene quel che finisce bene...
  • Re: Perché esistono in OOP le visibilità?

    Perché io stavo incominciando a studiare la programmazione a oggetti. Attraverso una guida su youtube e l'ho trovata molto semplice da seguire.
    Questa guida: https://www.youtube.com/watch?v=Dm1SNnxQxHE&list=PLdtVpbcGjJ9pgh1Agxz6eStgkU4iddNQ6&index=39&ab_channel=GianlucaScocozza
    Ora sto riuscendo a districarmi con le classi, le visibilità soprattutto, a cosa si può accedere a cosa no e come ecc...
    Però ovviamente, non avendo un progetto da fare, non capivo bene quando era preferibile utilizzarle, in che contesti ecc.
Devi accedere o registrarti per scrivere nel forum
5 risposte