Visualizzazione dei risultati da 1 a 6 su 6
  1. #1
    Utente di HTML.it L'avatar di Nikopol
    Registrato dal
    Jan 2011
    Messaggi
    120

    Dubbio sull'incapusulamento

    Ciao a tutti, qualche giorno fa ho sestenuto l'esame di programmazione 1 e la correzione di uno degli esercizi mi ha laciato molto perplesso.
    Avevamo 2 classi :
    codice:
    public class Libro{
         private String titolo;
         private int numeroPagine;
         //costruttore e get-set
    }
    public class Biblioteca{
         private Libro [] libri;
         private int size;
         private int index;
         //costruttore
         
    
    }
    dovevamo scrivere alcuni metodi tra cui aggiungiLibro.
    io ho scritto
    codice:
    public boolean aggiungiLibro(Libro libro){
         //aggiungo libro
    }
    La correzione del prof è stata: Esercizio sbagliato perchè l'incapsulamento è stato violato, non si può passare un oggetto a un metodo ma solo i suoi attributi.
    Il metodo secondo lui corretto era:
    codice:
    public boolean aggiungiLibro(String titolo, int numeroPagine){
        Libro libro = new Libro(titolo,numeroPagine);
        //ora posso aggiungerlo
    }
    Io non riesco a capire come l'incapsulamento risulta violato in questo modo. Mi rendo conto che così si disaccoppia il reference del libro ma non capisco la sua utilità; bisognerà sempre passare per i metodi get-set per accedere o modificare lo stato dell'oggetto.
    Qualcuno potrebbe illuminarmi per favore?

  2. #2
    Utente di HTML.it L'avatar di andbin
    Registrato dal
    Jan 2006
    residenza
    Italy
    Messaggi
    18,284
    Quote Originariamente inviata da Nikopol Visualizza il messaggio
    Esercizio sbagliato perchè l'incapsulamento è stato violato, non si può passare un oggetto a un metodo ma solo i suoi attributi.
    Se il concetto di Biblioteca è di essere poco più che un "insieme" (sequenza) di libri (nascondendo giusto solo la implementazione della struttura dati interna) ..... non c'è nulla di strano o sbagliato nel passare o ricevere oggetti Libro.
    Se il prof, per qualunque motivo, voleva che sia solo Biblioteca a poter istanziare i Libro, è una scelta implementativa, discutibile ma fattibile. Il punto è che doveva precisarlo prima ... se non l'ha fatto non può appellarsi alla "violazione" dell'incapsulamento. Mi spiace ... (per il prof ).
    Andrea, andbin.devSenior Java developerSCJP 5 (91%) • SCWCD 5 (94%)
    java.util.function Interfaces Cheat SheetJava Versions Cheat Sheet

  3. #3
    Quote Originariamente inviata da Nikopol Visualizza il messaggio
    Ciao a tutti, qualche giorno fa ho sestenuto l'esame di programmazione 1 e la correzione di uno degli esercizi mi ha laciato molto perplesso.
    Avevamo 2 classi :
    codice:
    public class Libro{
         private String titolo;
         private int numeroPagine;
         //costruttore e get-set
    }
    public class Biblioteca{
         private Libro [] libri;
         private int size;
         private int index;
         //costruttore
         
    
    }
    dovevamo scrivere alcuni metodi tra cui aggiungiLibro.
    io ho scritto
    codice:
    public boolean aggiungiLibro(Libro libro){
         //aggiungo libro
    }
    La correzione del prof è stata: Esercizio sbagliato perchè l'incapsulamento è stato violato, non si può passare un oggetto a un metodo ma solo i suoi attributi.
    Il metodo secondo lui corretto era:
    codice:
    public boolean aggiungiLibro(String titolo, int numeroPagine){
        Libro libro = new Libro(titolo,numeroPagine);
        //ora posso aggiungerlo
    }
    Io non riesco a capire come l'incapsulamento risulta violato in questo modo. Mi rendo conto che così si disaccoppia il reference del libro ma non capisco la sua utilità; bisognerà sempre passare per i metodi get-set per accedere o modificare lo stato dell'oggetto.
    Qualcuno potrebbe illuminarmi per favore?
    In effetti neanche io capisco di cosa si lamenti il prof se il metodo aggiungiLibro appartiene alla classe Biblioteca come sembra ovvio

    Al limite avrebbe potuto anche avere ragione se avesse chiesto una una cosa del genere
    (... lavoro di fantasia solo per esporre un caso in cui potrebbe avere senso passare solo gli attributi):

    "implementare un metodo getDifferenzaPagine nella classe Libro"
    e si fosse scritto :

    public class Libro{
    private String titolo;
    private int numeroPagine;
    //costruttore e get-set
    ...
    public int getDifferenzaPagine( Libro altroLibro) {
    // qui posso accederere direttamente alle var private di altroLibro
    altroLibro.numeroPagine=-100;
    ....
    }
    }

    ... ma non ha chiesto nulla del genere

    Se ci sono sviluppi fai sapere come va a finire perché la curiosità è forte
    Ultima modifica di sspintux; 15-02-2014 a 00:03

  4. #4
    Utente di HTML.it L'avatar di Nikopol
    Registrato dal
    Jan 2011
    Messaggi
    120
    Grazie per le risposte, almeno ora ho la conferma che non avevo scritto boiate nell esercizio .
    Comunque il professore non aveva chiesto nulla del genere, pretende che si programmi sempre in questo modo; in più chiedendogli spiegazioni mi son sentito dire che passando un oggetto a un metodo si espone il puntatore (puntatore in java???) e quindi può essere modificato da qualsiasi punto del programma rendendo inutile usare l'incapsulamento.
    Ho provato a farlo ragionare ma non c'è stato verso di fargli cambiare idea.
    Risultato: lui è il prof e ha sempre ragione e io e i miei compagni, i quali hanno svolto l'esercizio nel mio stesso modo, abbiamo tutti torto.
    Ridarò l'esame scrivendo come piace a lui per avere un voto più alto e poi cancellerò dalla mia memoria tutto quello che ha detto.
    Ultima modifica di Nikopol; 16-02-2014 a 21:23

  5. #5
    Quote Originariamente inviata da Nikopol Visualizza il messaggio
    ...
    Risultato: lui è il prof e ha sempre ragione e io e i miei compagni, i quali hanno svolto l'esercizio nel mio stesso modo, abbiamo tutti torto.
    Ridarò l'esame scrivendo come piace a lui per avere un voto più alto e poi cancellerò dalla mia memoria tutto quello che ha detto.
    La spiegazione data dal prof che hai riportato non aggiunge nulla di nuovo a me comprensibile;

    .... l'antica saggezza contadina , a te ben nota a quanto leggo, recita appunto :
    "lega l'asino dove dice il padrone ...anche se forse sarebbe meglio legare il padrone dove dice l'asino"
    Ultima modifica di sspintux; 16-02-2014 a 22:22

  6. #6
    Utente di HTML.it L'avatar di andbin
    Registrato dal
    Jan 2006
    residenza
    Italy
    Messaggi
    18,284
    Quote Originariamente inviata da Nikopol Visualizza il messaggio
    mi son sentito dire che passando un oggetto a un metodo si espone il puntatore (puntatore in java???) e quindi può essere modificato da qualsiasi punto del programma rendendo inutile usare l'incapsulamento.
    Se a un costruttore/metodo passi un reference, il costruttore/metodo riceve effettivamente una copia del reference. Vuol dire che il costruttore/metodo non può cambiare il valore del reference che ha il chiamante (es. in una variabile) ma può eventualmente cambiare lo "stato" dell'oggetto referenziato, se l'oggetto è "mutabile". Questo sì.

    Nel tuo caso Libro è "mutabile", poiché ha i metodi setter. Ora ... per quello che dovevi fare è un problema questo? Dipende ... probabilmente no.
    E comunque l'incapsulamento non è o diventa inutile! L'incapsulamento serve principalmente per nascondere i dettagli interni di uno stato e/o comportamento. Se tu volessi mettere in Libro un controllo per cui il 'numeroPagine' non deve essere negativo, puoi farlo perché il campo è private (non accessibile dall'esterno) e lo puoi settare solo da costruttore o metodo setter. E qui puoi fare il controllo, lanciando es. IllegalArgumentException se il valore è negativo.
    A questo serve l'incapsulamento.

    Quote Originariamente inviata da Nikopol Visualizza il messaggio
    Ridarò l'esame scrivendo come piace a lui per avere un voto più alto e poi cancellerò dalla mia memoria tutto quello che ha detto.
    Sì .. direi che vista la situazione/premessa, è l'unica soluzione valida per te.
    Andrea, andbin.devSenior Java developerSCJP 5 (91%) • SCWCD 5 (94%)
    java.util.function Interfaces Cheat SheetJava Versions Cheat Sheet

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.