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

Question

Я обнаружил, что у меня есть несколько мест, где общедоступные статические внутренние классы, расширяющие «вспомогательные» классы, делают мой код намного более безопасным и, на мой взгляд, читабельным.Например, представьте, что у меня есть класс SearchCriteria.Есть много общего в разных вещах, которые я ищу (условие поиска, а затем группа типов поисковых запросов, диапазон дат и т. д.). Расширяя его в статическом внутреннем классе, я тесно связываю расширение и возможность поиска. класс со специфическими отличиями.Этот кажется теоретически это плохая идея (плохая тесная связь!), но расширение специфично для этого класса с возможностью поиска (один класс, одна цель).

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

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

Answer 1

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

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

Answer 2

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

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

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

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

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

Answer 3

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

Answer 4

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