Никогда не использовать общедоступные вложенные перечисления?

Недавно я столкнулся с стандартом кодирования, утверждающим, что вы должны никогда использовать общедоступные внутренние перечисления/классы в Java. Это первый случай, когда я столкнулся с этим соглашением и не смог найти удовлетворительного объяснения относительно того, почему.

Я понимаю, почему следует избегать публичных внутренних классов, но по каким причинам вы никогда не будете использовать общедоступные вложенные перечисления? Или, почему это плохое соглашение, чтобы следовать?

Ответ 1

Отказ от ответственности: Ниже приведены не жесткие и быстрые правила. Это только мои мнения и личные предпочтения. Я лично считаю, что это упрощает чтение кода и упрощает его работу.

Сначала вопрос. Где вы столкнулись с этим советом? Были ли они обоснованы?

По моему опыту, я обычно использовал частные вложенные перечисления для повышения удобочитаемости и ремонтопригодности моего кода. Это особенно вступает в игру, когда вы выполняете интеграцию с другой системой, и вам нужно отправлять определенные строки или номера. Я считаю, что использование перечисления облегчает чтение и обслуживание. В этом конкретном случае информация, передаваемая перечислением, ограничена по охвату классу (т.е. Она не имеет никакого смысла вне класса, и никто другой не нуждается в ней).

Я не могу придумать окончательную причину, в которой говорится, почему публичные внутренние перечисления являются плохой практикой. Но вот причины, по которым я их не использую (обычно):

Если перечисление является общедоступным, это по существу означает, что оно передает информацию в большей области (то есть имеет смысл вне сферы действия его родительского класса, и поэтому, вероятно, это означает, что другие вещи используют его). Если это так, то может иметь смысл сделать это автономным перечислением.
Я нахожу его ThirdPartyResponseCodes.Success проще для глаз, а не ThirdPartyIntegrationInterface.ThirdPartyResponseCodes.Success. Нет причин, по которым вы не можете назвать перечисление соответствующим образом для предоставления контекста и, таким образом, сделать его автономным перечислением.
Я бы предположил, что те же причины не использовать общедоступные внутренние классы также применимы к общедоступным внутренним перечислениям. Прежде всего, если у вас есть внутренний класс, это может означать, что ваш внешний класс может извлечь выгоду из рефакторинга. Возможно, ваш внешний класс пытается сделать слишком много? Однако с другой стороны, существует преимущество инкапсуляции и ограничения области, особенно если вы можете сделать аргумент о том, что внутренний класс имеет смысл только в контексте внешнего класса (который должен идти, если не говорить, если он является конфиденциальным). Если это общедоступный внутренний класс, то это, вероятно, означает, что его область действия простирается за внешний класс и, следовательно, его нужно будет вытащить.
Если вам действительно нужно использовать публичное вложенное перечисление, тогда вы должны точно документировать, зачем вам это нужно (я еще не нашел причины сделать это) и почему лучше оставить его в качестве общедоступного вложенного перечисления а не публичное автономное перечисление.

Ответ 2

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

Ответ 3

Вам нужно будет спросить человека, который написал этот стандарт кодирования, если он не содержит объяснений. Однако это ваше утверждение несколько сбивает с толку:

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

Почему, по-вашему, следует избегать общественных внутренних классов? И почему эта причина не относится к перечислениям?