Avantages et inconvénients des packages de classes privées en Java?

Question

Je suis en train d'apprendre le Java récemment, et je suis tombé sur la notion d' package-private classes, ce qui est la valeur par défaut si l'on ne spécifie pas quoi que ce soit. Mais ensuite j'ai réalisé:

1. J'ai rarement voir l'utilisation de la trousse-classe privée. Est-il une raison pour cela, par exemple, il a de graves inconvénients, il est redondant, ou tout simplement je ne suis pas la lecture assez? Sont il y a de solides arguments pour/contre son utilisation?

2. Si ce n'est pas vraiment utile dans la plupart des cas, pourquoi en serait-il par défaut?

3. Dans quelle situation faut-il utiliser colis-privé dans le monde réel? I. e., quand serait-elle irremplaçable?

En d'autres termes, quels sont les principaux avantages et inconvénients du package par défaut-privé modificateur?

Merci à vous tous!

Answer 1

La réponse courte est - elle est un peu plus large que la forme de privé.

Je vais supposer que vous êtes familier avec la distinction entre public et private, et pourquoi il est généralement préférable de faire les méthodes et les variables private s'ils vont être utilisées uniquement en interne à la classe en question.

Eh bien, comme une extension de celle - là, si vous songez à la création de votre logiciel de façon modulaire, vous pourriez penser à un public d'interface à votre module, qui aura plusieurs classes à l'intérieur de collaboration entre eux. Dans ce contexte, il est parfaitement logique de faire des méthodes d' public s'ils vont être appelés par les consommateurs; private s'ils sont internes à une classe; et package private s'ils sont utilisés pour effectuer des appels entre les classes de ce module, c'est à dire que c'est un détail de l'implémentation de votre module (tel que vu par le public, les appelants), mais s'étend sur plusieurs classes.

Ce n'est que rarement utilisé dans la pratique, parce que le système de paquets s'avère ne pas être si utile pour ce genre de chose. Vous devez vider toutes les classes pour un module donné dans exactement le même paquet, qui pour quoi que ce soit non trivial va devenir un peu lourd. Donc, l'idée est excellente - faire une méthode accessible à seulement une poignée de "proximité" classes à la fois, un peu plus large private - mais les restrictions sur la façon de définir l'ensemble des classes signifie qu'il est rarement utilisé et/ou utiles.

Answer 2

Une chose intéressante à propos de package-private est que vous pouvez l'utiliser pour donner accès à des méthodes que vous considéreriez autrement comme privées à des classes de test unitaires. L'inconvénient est bien sûr que d'autres classes du package pourraient l'appeler alors qu'elles ne devraient vraiment pas.

Answer 3

En dehors de l'encapsulation, l'un des principaux avantages de l'utilisation du package privée les classes, c'est qu'ils n'apparaissent pas dans la javadoc de votre projet. Donc, si vous utilisez des classes d'assistance qui n'ont pas d'autre usage, mais pour aider votre public des classes de faire quelque chose que les clients ont besoin, il est logique de les rendre colis privé que vous voulez garder les choses aussi simples que possible pour les utilisateurs de la bibliothèque.

Comme un exemple, vous pouvez avoir un coup d'oeil à une bibliothèque que j'ai développé. La javadoc ne contient que 5 interfaces et 12 classes, bien que le code source a beaucoup plus. Mais ce qui est caché est la plupart du temps des couches internes qui n'apportent aucune valeur ajoutée pour le client (généralement toutes les classes de base abstraites sont cachés).

Il y a aussi de nombreux exemples dans le JDK.

Answer 4

Concernant la question du "pourquoi serait-il la valeur par défaut", dans ce contexte, le terme "défaut" signifie simplement l'absence d'un autre qualificatif. Je suppose qu'ils pourraient avoir inventé un autre mot clé ("package" était déjà pris), mais ils n'ont pas.

Dans le monde réel, j'utilise d'accès par défaut de l'utilitaire de classes et les classes abstraites que je ne veux pas que les gens appel ou autrement utiliser d'autres paquets. Disons que vous disposez d'une interface et de deux des implémentations concrètes qui s'étendent de certaines classe abstraite. Vous déclarez vos deux classes concrètes comme finale parce que vous n'avez pas forcément envie les gens à la sous-classe (voir Effective Java). Vous ne voulez pas que les gens de singe avec votre classe abstraite pour la même raison. Si vous utilisez d'accès par défaut pour la classe abstraite, alors les gens ne voient que si ils ont mis leur classe dans votre forfait. Ce n'est pas l'épreuve des balles, mais je pense que c'est une utilisation raisonnable/illustration d'accès par défaut. Cela dit, le fait qu'elle n'empêche pas les détails de la fuite comme privé serait, c'est à dire ne pas garantir quoi que ce soit, signifie qu'il n'est pas particulièrement utile de la convention.

Une autre raison pourquoi vous n'avez pas la voir plus souvent utilisé est que les gens ont tendance à exclure les classes d'accès par défaut à partir de leur documentation javadoc.

Answer 5

1 - cela Dépend de l'architecture -Généralement si vous écrivez du code pour vous-même et sur de petits projets, vous n'auriez probablement pas l'utiliser. Dans les grands projets, il peut être utile de s'assurer que vous pouvez contrôler où et comment certaines méthodes sont appelées.

2 - par Défaut (I. e. pas public/protected/private) n'est pas la même privé de son 4e état. Voir Java De Contrôle D'Accès

3 - Il peut rendre la vie plus facile lorsque vous êtes à l'écriture de bibliothèques que vous ne voulez pas que des tiers, en s'appuyant sur la façon dont vous mettez en œuvre le code sous-jacent - vous venez de faire l'API elle-même publique.