Il existe des opinions différentes sur des classes intérieures simples, alors je me demandais s'il y a un consensus général sur ce qui est bon et quand utiliser des classes intérieures privées.
Voici un exemple que j'ai trouvé, et pour lequel je pense qu'il est inutile de créer une classe intérieure. Quelle est la qualité / la mauvaise pratique? P>
private static class InternalCounter {
int count;
public InternalTabManager() {
count = 0;
}
public int increment() {
return count++;
}
}
6 Réponses :
Ouais, dans ce cas, il semble très inutile, mais si vous avez un cas où il y a une fonctionnalité significative et que vous savez qu'aucune autre classe n'aura besoin de votre classe intérieure et qu'il n'a aucun sens de créer une classe plus globalement disponible dans le monde disponible. Ensuite, utilisez une classe intérieure.
Merci, j'accepterai cette réponse comme après avoir lu la question connexe ici pour confirmer qu'il s'agit d'un cas assez inutile et ajoute une complexité inutile
Lorsque vous souhaitez hériter (prolongé) plusieurs classes dans une classe Java, vous pouvez utiliser le concept de classe intérieure.Eerez que vous pouvez prolonger une classe par classe extérieure et une autre par classe intérieure.
Cela dépend du contexte. Si cette classe aurait pu être remplacée par un seul article statique, je ne vois pas besoin de créer une classe intérieure.
D'autre part, ce code permettrait aux objets de la classe mère de partager une référence à l'INT mutable (à l'aide de Java.Lang.Integer ne serait pas possible car est immuable).
Le conseil général / la pratique / motif dans ce cas est Il est simple et vous n'en aurez pas besoin - si vous n'avez pas besoin de comportement particulier, ne faites pas votre code plus complexe que ce qui est absolument nécessaire.
Donc, si la question est la suivante: "Est-il une bonne pratique de créer une classe interne pour une fonctionnalité simple, quand elle aurait pu être résolue de manière plus simple" alors la réponse est
Lorsque rencontré avec de telles situations, nous demandons normalement aux développeurs de se demander -
Les auditeurs, les présentateurs (modèle d'interface utilisateur) sont des aspects fonctionnels; et mériter une existence séparée et sont rarement modélisés comme des classes intérieures statiques
Entrées d'audit, les constructions d'initialisation sont des aspects non fonctionnels / organisation-organisation; et ne donnez pas une réponse définitive et imo il est correct d'utiliser des classes intérieures statiques
Un exemple définitif pour utiliser tel, serait un modèle de transition d'état pour une petite application.
Ma règle echalique consiste à utiliser des classes intérieures statiques si, dans une seule classe, vous avez refacturé à une poignée de méthodes privées qui prennent chacune des paramètres similaires (ou identiques) à chaque fois. Dans ce cas, j'aime bien regrouper ces paramètres dans une seule classe intérieure de sorte que j'ai un type qui décrit succincemment pourquoi ces paramètres sont regroupés.
J'ai aussi utilisé des classes intérieures de cette manière, mais de nos jours, j'ai tendance à rendre ces classes package-privé.
Vous obtenez tous les avantages de la classe intérieure, tandis que ces deux classes sont beaucoup mieux à maintenir (être dans deux fichiers distincts).
Oui, il est toujours possible qu'une classe dans le même paquet utilise la classe accidentellement, mais il est très peu susceptible de se produire.
Avez-vous regardé ceci: Stackoverflow.com/Questtions/2284396/...