Тесно интегрированный частный класс помощника в ASP.NET
Полуневажный фон: я работаю на странице с двумя наборами разборных панелей. (использующий nHibernate) я получаю объекты категории со списком объектов в них, и для каждой категории генерируют левую панель и правильную панель. В обеих панелях существует ListBox. Объекты предварительно заполняются к левому полю списка, и пользователь может выбрать и переместить объекты в правильное поле списка (под соответствующей категорией.)
Поскольку я создал и работал над ним, я закончил с большим количеством общих методов как buildPanel (сторона, categoryID) и затем закончил с большим количеством повторных если операторы в них для дифференциации между этими двумя сторонами
if type=PanelType.Left then
set these 5 id strings to access components
else
...
Код стал грязным, таким образом, я переместил много логических и статических строк разработчика для идентификаторов компонента в частный класс помощника для создания других частей основного класса легче читать и следовать. Проблема, которую я вижу, состоит в том, что частный класс является чрезвычайно иждивенцем на определенных структурах в родительском классе. Существует очень минимальный объем продолжения инкапсуляции, и я возможно делаю логику тяжелее, чтобы следовать, даже если отдельные компоненты в коде легче считать.
Мой вопрос: То, когда Вы используете частный класс как это, является им приемлемый, чтобы тесно интегрировать его с родительским классом (так как это является частным и реализовано в том же файле), я лучше, чтобы осуществить рефакторинг снова и найти, что способ любого упрощения моего исходного кода максимально короток без класса помощника (засуньте все функции категории/панели в одно место и скройте их в их собственном регионе, когда я не использую их), или если я двигаю помещение большего количества логики в классе помощника и просто отображении моих событий непосредственно к подклассу.
После вывода всего этого я склоняюсь к последней опции, но я все еще рвусь/путаюсь обо всем этом...
2 ответа
Страницы - это классы, и, как любой класс, они могут стать громоздкими. Когда вы подойдете к стадии, когда код сильно связан, это как бы зависит от того, как эта связь показывает, следует ли вам проводить рефакторинг. Если код ясен, краток и прост для понимания, можно оставить его как есть. Но если это сложно понять, если вы не можете объяснить это коллеге за несколько минут или думаете, что сами не поймете через полгода, тогда это имеет право на рефакторинг.
Закон Деметры (световая связь) должен применяться не только в отношениях между классами, но также и в отношениях между методами. Это часто упускается из виду или недооценивается. Но иногда слишком много рефакторинга приводит к другой крайности: слишком слабое связывание также может стать нечитаемым (точно так же, как слишком много маленьких методов или слишком много больших).
Я обычно задаю себе вопрос: читается ли код как книга с четкими главами и сюжетной линией, или мне нужно читать каждый абзац дважды или, что еще хуже, переворачивать страницы, чтобы понять его?
Если вы никогда не используете этот механизм панели на другой странице, то вам не нужно проводить рефакторинг.
Более того, пока вам не понадобится использовать его на другой странице, вы не знаете, как реорганизовать частный класс, чтобы сделать его повторно используемым.