données protégées dans la classe abstraite

Pense protégé méthodes interface pour les sous-classes, de la même manière que les méthodes publiques sont une interface pour tout le monde.

Fournir des accesseurs permet à la classe de base afin de maintenir son état: il n'y a aucune façon une sous-classe peut corrompre sans intentionnelle truc.

Si vous n'avez pas besoin de votre enfant à directement y accéder, pourquoi voudriez-vous laisser ?

Ce n'est pas un inconvénient à l'utilisation protégé. Mais si il n'est pas nécessaire, peut-être que c'est mieux de l'éviter et de contrôler l'accès à vos champs.

Si quelqu'un de votre sous-classes de la classe, et met le sous-classe dans le même package que votre classe actuelle, ils veulent peut-être remplacer votre getters et setters. Par exemple, ils wantto assurez-vous que i ne peut être réglé à une valeur supérieure à 1.

Autre que cela, il est vraiment à vous. La convention est qu'il y a des getters et setters pour tout cela.

Vous souhaitez utiliser des getters/setters, parce que l'utilisation protected int i; permet de champ primordial (qui vous voulez éviter à tout prix).

Vous voulez interdire le champ primordial car il fonctionne différemment de la redéfinition de méthode. Champ primordial de ne pas faire le substituée champ inaccessible (le type de la référence détermine l'exemple de la zone que vous travaillez avec).

Accessibles de domaines devraient être définitifs ou dans une classe, qui est définitive.

public class OverridingFun {
    public static class Base {
        public int i = 1;
        public int getI(){ return i; }
    }
    public static class A extends Base {
        public int i = 2;
        public int getI(){ return i; }
    }
    public static class B extends A {
        public int i = 3;
        public int getI(){ return i; }
    }
    public static void main(String [] args){
        B b = new B();
        A bAsA = b;
        Base bAsBase = b;

        System.out.println(b.getI());//3
        System.out.println(bAsA.getI());//3
        System.out.println(bAsBase.getI());//3

        System.out.println(b.i);//3
        System.out.println(bAsA.i);//2
        System.out.println(bAsBase.i);//1

        b.i = 4;
        bAsA.i = 5;
        bAsBase.i = 6;

        System.out.println(b.i);//4
        System.out.println(bAsA.i);//5
        System.out.println(bAsBase.i);//6
    }
}

À première vue, cela ressemble à quelque chose qui serait tout simplement de rendre le code difficile à lire, mais elle a des conséquences sur la fonctionnalité. Dire que le champ est remplacée par une classe dérivée, depuis les poseurs ne sont pas utilisés, il n'existe aucun moyen pour automatiquement mettre à jour le champ de base et aucun moyen de détecter si quelqu'un a modifié le champ de base (puisque la valeur de base est toujours accessible) et mise à jour de la dérivée du champ. Il est facile d'imaginer que la base et les états dérivés pourrait sortir de la synchronisation et que les erreurs sont difficiles à dépister. Il suffit de le mettre en fait un très fragiles API.

Malheureusement, il n'existe aucun moyen de se prémunir contre cette depuis la final mot-clé, qui protège contre l'écrasement, rend également les champs de l'écriture une fois. Donc pas accessible en écriture non-overloadable champs.

Personnellement, je suis plutôt surpris de la langue concepteurs ont permis de primordial. L'avantage de l'utilisation de poseurs est que chaque niveau de la garantie de l'intégrité de son propre état et de la confiance que les classes dérivées n'ai pas accroché. Champ primordial est juste des ennuis.