Является ли хорошей практикой создание внутреннего класса для простой функциональности?

Question

Есть несколько разных мнений о простых внутренних классах, поэтому мне было интересно, существует ли общее согласие относительно того, что хорошо, и когда использовать частные внутренние классы.

Вот пример, который я нашел, идля которого я думаю, что нет необходимости создавать внутренний класс.Насколько это хорошо / плохо?

private static class InternalCounter {
  int count;

  public InternalTabManager() {
    count = 0;
  }

  public int increment() {
    return count++;
  }
}

Имейте в виду, что в данном конкретном случае один экземпляр хранится в окружающем классе для отслеживания количества.

Answer 1

Да, в этом случае это кажется очень ненужным, но если у вас есть случай, когда есть какая-то существенная функциональность, и вы знаете, что никакой другой класс никогда не будет нуждаться в вашем внутреннем классе, и нет смысла создавать класс более доступным для всех затем используйте внутренний класс.

Answer 2

Это зависит от контекста. Если бы этот класс мог быть заменен только одним статическим int, то я не вижу необходимости создавать внутренний класс.

С другой стороны, этот код позволил бы объектам родительского класса совместно использовать ссылку на изменяемый объект int (использование java.lang.Integer было бы невозможным, поскольку он неизменен).

Общий совет / практика / шаблон в этом случае: Сохраняйте это простым и вам это не нужно - если вам не нужно определенное поведение, не делайте ваш код более сложным, чем абсолютно необходимо.

Итак, если вопрос таков: «Является ли хорошей практикой создание внутреннего класса для простой функциональности, когда его можно было бы решить более простым способом», тогда ответ будет НЕТ .

Answer 3

Когда мы сталкиваемся с такими ситуациями, мы обычно просим разработчиков задаться вопросом -

• Насколько государственным будет этот объект? Эта функциональность связана с содержащим классом?
• Может ли это быть отдельным объектом? (цель и причина существования)
• Самое главное, это чище?

Слушатели, докладчики (модель пользовательского интерфейса) - это функциональные аспекты; и заслуживают отдельного существования и редко моделируются как статические внутренние классы

Аудит записей, конструкции инициализации - это нефункциональные аспекты / аспекты организации кода; и не дают определенного ответа, и IMO можно использовать статические внутренние классы

Определенным примером для использования такой модели будет модель перехода состояния для небольшого приложения.

Answer 4

Я также использовал внутренние классы таким образом, но в настоящее время я склонен делать эти классы закрытыми.

Вы получаете все преимущества внутреннего класса, тогда как эти два класса гораздо удобнее поддерживать (в двух отдельных файлах).

Да, все еще возможно, что класс в том же пакете использует класс случайно, но это ОЧЕНЬ маловероятно.

Answer 5

Мое эмпирическое правило состоит в том, чтобы использовать статические внутренние классы, если в пределах одного класса вы реорганизовали несколько частных методов, каждый из которых каждый раз принимает одинаковые (или одинаковые) параметры.В этом случае я хотел бы сгруппировать эти параметры вместе в один внутренний класс, чтобы у меня был тип, который кратко описывает, почему эти параметры сгруппированы вместе.

Answer 6

Если вы хотите наследовать (расширять) более одного класса в одном классе Java, вы можете использовать концепцию внутреннего класса. Здесь вы можете расширить один класс внешним классом, а другой - внутренним классом.