Les constantes statiques enfreignent-elles la "encapsulation"?

Je ne pense pas que Static vient sous le principe de OOP. Donc il ne viole ni ne manque.

Les littéraux statiques ne font partie d'aucun objet, ce ne sont que des données attribuées à une variable globale pour convaincre. Ainsi, ce n'est pas une violation de l'encapsulation en soi, mais un manque total d'orientation de l'objet.
La voie de l'OOP n'est pas de ne pas avoir une constante globale du tout et de définir un objet qui répond à votre problème.

interface Figure {
    double perimeter();
}
class Circle implements Figure {
    private final double radius;

    @Override
    public double perimeter() {
        return this.radius * 2 * (float) 3.1416926; 
    }
}

Grande question. Je ne pense pas que les exemples que vous avez fournis l'encapsulation de pause, du moins pas strictement.

Le premier exemple que vous avez donné est le PI constant et le second est un exemple qui donne accès à la constante de sortie dans le système; Vraisemblablement pour utiliser un code tel que system.out.println ("helloworld!"); . Comme d'autres les ont déjà mentionnés, pi est efficacement juste une constante et des utilisateurs de la constante n'ont aucun moyen par lequel modifier ou influencer la valeur. Les utilisateurs de PI doivent encore référencer la constante (qui constitue l'API ici) dans leur code. Si PI a été modifié (improbable, mais qui sait qui sait) les utilisateurs seraient à l'abri de l'implication de ce changement car ils seraient obligés de recompiler le code de toute façon.

une manière utile. Pour penser à l'encapsulation, c'est penser à ce qui serait nécessaire pour violer l'encapsulation. Efficace Java 3rd Edition décrit ce puits dans le point 16, suggérant que sans encapsulation appropriée "Vous ne pouvez pas modifier la représentation sans changer l'API, vous ne pouvez pas appliquer les invariants et vous ne pouvez pas prendre des mesures auxiliaires lorsqu'un champ est accessible. "

Une violation très claire de ce qui précède serait la classe suivante (également dans le point 16 de Java efficace): xxx

Tous les champs sont publics et Les utilisateurs de cette API seraient obligés d'utiliser directement les champs. Si, plus tard, l'auteur a décidé d'ajouter une vérification de la validation avant x ou y peut être consulté ou modifié, il serait alors impossible de le faire sans casser potentiellement les clients existants. L'API devrait être significativement modifiée et briser probablement le comportement des utilisateurs en aval.

examinons maintenant le deuxième exemple que vous avez fourni: xxx

ceci Semble très similaire à l'exemple de PI ci-dessus, mais il y a une différence clé: le champ en question est une imprimante. Tandis que le champ OUT est une partie claire de cette API qui peut maintenant être difficile à modifier (maintenant que les clients exposés vont utiliser et compter sur elle), le PrintStream Type est une classe qui est en fait ce qui est intéressant ici: les utilisateurs seront des méthodes de référencement sur la classe. Ici, nous avons la fonctionnalité clé dans l'API de PrintStream qui peut être évolué au fil du temps sans casser l'utilisation. Il est également possible à l'avenir d'avoir le constant modifié pour se reporter à un autre impressionnant Sous-classe et les utilisateurs de l'API ne doivent pas être affectés.

Espère que cela aide.