Статические внутренние классы - хорошая идея или плохой дизайн?

Question

Я обнаружил, что у меня есть несколько мест, в которых есть открытые статические внутренние классы, которые расширяют классы "помощника", что делает мой код намного более безопасным и, на мой взгляд, читабельным. Например, представьте, что у меня есть класс "SearchCriteria". Существует много общих черт для различных вещей, которые я ищу (поисковый запрос, а затем группа типов поисковых терминов, диапазон дат и т. Д.). Расширяя его в статическом внутреннем классе, я тесно связываю расширение и доступный для поиска класс с конкретными отличиями. Это кажется теоретически плохой идеей (Tight Coupling Bad!), Но расширение специфично для этого класса с возможностью поиска (One Class, One Purpose).

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

Кроме того, я не уверен, является ли это вики-материалом сообщества или нет.

Answer 1

Звучит совершенно разумно для меня. Делая его внутренним классом, вы облегчаете поиск и очевидный кандидат на проверку при изменении класса поиска.

Тесная связь плоха только тогда, когда вы соединяете вещи, которые на самом деле не принадлежат друг другу, только потому, что одна из них вызывает другую. Для классов, которые тесно сотрудничают, например, когда, как в вашем случае, один из них существует для поддержки другого, тогда это называется «сплоченность», и это хорошая вещь .

Answer 2

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

Answer 3

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

В Python у нас есть множество структур.

1. пакеты. Они содержат модули. По сути, это каталоги с небольшим количеством машин Python.

2. Модули. Они содержат классы (и функции). Это файлы; и может содержать любое количество тесно связанных классов. Часто бизнес "внутреннего класса" обрабатывается на этом уровне.

3. Классы. Они могут содержать определения внутреннего класса, а также функции метода. Иногда (не очень часто) внутренние классы могут фактически использоваться. Это редко, поскольку связь между классами на уровне модулей обычно совершенно ясна.

Answer 4

Смысл "слабой связи" заключается в том, чтобы два класса были разделены, чтобы в случае изменений кода в вашем классе "SearchCriteria" ничего не пришлось менять в других классах. Я думаю, что статические внутренние классы, о которых вы говорите, потенциально могут сделать поддержание кода кошмаром. Одно изменение в SearchCriteria может отправить вам поиск по всем статическим классам, чтобы выяснить, какие из них теперь повреждены из-за обновления. Лично я бы держался подальше от любых таких внутренних классов, если это действительно не нужно по какой-то причине.