Visualizzazione dei risultati da 1 a 5 su 5
  1. #1

    Protected è superfluo?

    Ciao a tutti, sono nuovo, mi chiamo Diego, piacere "conoscervi" :-).
    Volevo proporre un piccolo problema, di quelle domande un pò sciocche.
    Spero di non essere andato troppo veloce, ma non mi sembra di aver visto nulla a riguardo.
    Allora, in Java sono andato sparato facendo un pò di tutto, anche progettini di medio/bassa complessità.
    A un certo punto sono tornato indietro perchè volevo approfondire la questione e iniziano a venire i dubbi anche più semplici.
    Mi stavo rivedendo e tastando i package, le clausole public, private, protected, e default e mi sono accorto che (lasciando perdere public e private):

    - Se due classi appartengono allo stesso package, anche se non c'è una relazione di ereditarietà tra di esse, la visibilità di package fa si che la classe che usa può comunque chiamare i metodi protected della classe che contiene il metodo o il campo desiderato.
    (in sostanza utilizzare default e utilizzare la clausola protected non cambia nulla)

    - Se due classi appartengono a diversi package, ma hanno una relazione di ereditarietà, ho visto che la sottoclasse non può comunque chiamare campi o metodi protected della superclasse, ma questa, per far si che le vengano letti i metodi o i campi dalle sue sottoclassi di altri package, questi devono essere comunque resi public.

    A questo punto, la clausola protected è superflua o mi potete spiegare un caso dove devo per forza utilizzare questa clausola?

  2. #2

    Re: Protected è superfluo?

    Originariamente inviato da mereudie
    - Se due classi appartengono a diversi package, ma hanno una relazione di ereditarietà, ho visto che la sottoclasse non può comunque chiamare campi o metodi protected della superclasse
    A me risulta che una sottoclasse puo' sempre accedere a campi protected della sua superclasse...

    Access level modifiers determine whether other classes can use a particular field or invoke a particular method. There are two levels of access control:

    * At the top level—public, or package-private (no explicit modifier).
    * At the member level—public, private, protected, or package-private (no explicit modifier).

    A class may be declared with the modifier public, in which case that class is visible to all classes everywhere. If a class has no modifier (the default, also known as package-private), it is visible only within its own package (packages are named groups of related classes—you will learn about them in a later lesson.)

    At the member level, you can also use the public modifier or no modifier (package-private) just as with top-level classes, and with the same meaning. For members, there are two additional access modifiers: private and protected. The private modifier specifies that the member can only be accessed in its own class. The protected modifier specifies that the member can only be accessed within its own package (as with package-private) and, in addition, by a subclass of its class in another package.

    (http://www.google.com/url?sa=t&sourc...ULvJsosncbTNvw)
    max

    Silence is better than bullshit.
    @mmarcon
    jHERE, Maps made easy

  3. #3
    Il problema è proprio questo, anche io prima di venire nel Forum ho visto che era esattamente come diceva lei, ma testando tutto con un semplice programmino il comportamento di questo mi ha dato ragione, inoltre sfogliando Thinking in Java ho trovato qualcosa che rende il mio dubbio legittimo:

    pag. 228 Thinking in Java, i Fondamenti

    ... Se generate un nuovo package ed ereditate da una classe presente in un altro package, gli unici membri cui avrete accesso sono quelli public del pacchetto originale, ....

    Poi ha svolto anche un esercizio facendo in sostanza quello che già avevo fatto per conto mio.

    Bisognerebbe rendere public quei metodi o campi, ma in quel caso sarebbero "visti" da tutti, e quindi anche da quelli indesiderati.

    Mi viene da pensare che l'unico modo per rendere indispensabile questa clausola protected sia quello di inserire sottoclasse e superclasse nello stesso package, in modo da garantire la lettura da parte della sottoclasse e allo stesso tempo impedire (con public), che utenti sconsiderati usino i metodi della mia superclasse.
    Comunque grazie, sembrano cavolate, ma sono quelle cosettine che fanno perdere punticini in esami tipo certificazioni ecc...:-) e i punti se ne vanno come la ghigliottina...

  4. #4
    Guarda, ero sicuro che fosse come dico io, ma per far essere sicuro anche te, ho appena fatto questo test, e compila senza problemi:

    codice:
    package us.ihmc;
    
    public class Test 
    {
        public Test()
        {
            _member = new Object();
        }
        
        protected Object _member ;
    }

    codice:
    package us.mmarcon;
    
    import us.ihmc.Test;
    
    public class TestSub extends Test
    {
        public TestSub()
        {
            super();
        }
        
        public void print()
        {
            System.out.println (_member);
        }
    }
    max

    Silence is better than bullshit.
    @mmarcon
    jHERE, Maps made easy

  5. #5
    Il mio obiettivo prima delle 10 era far si che lei avesse ragione.
    Ho fatto un errore di distrazione.
    Il programma era simile al suo come struttura, ma nella sottoclasse avevo messo un main che diceva:

    Animal a = new Dog();
    a.metodo_protected();

    --> non compila (metodo_protected has protected access in superclassi.Animal)

    Mentre:

    Dog a = new Dog();
    a.metodo_protected();

    --> compila

    Risolto questo dubbio, adesso rivedere nel dettaglio un pò di ereditarietà non sarebbe male.
    Era ovvio che avevi ragione, così doveva essere, non era un problema di modificatori di accesso.
    Comunque grazie.

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.