Плотно интегрированный частный вспомогательный класс в ASP.NET

Question

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

Поскольку я создавал и работал над этим, у меня появилось много общих методов, таких как buildPanel (side, categoryID), а затем я получил много повторяющихся операторов if для различения двух сторон

if type=PanelType.Left then 
    set these 5 id strings to access components
else
    ...

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

У меня такой вопрос: когда вы используете такой закрытый класс, допустимо ли его тесно интегрировать с родительским классом (поскольку он закрытый и реализован в том же файле), лучше ли мне снова провести рефакторинг и найти способ либо упростить мой исходный код до как можно более короткого без вспомогательного класса (поместите все функции категории / панели в одно место и скройте их в своем регионе, когда я их не использую), или я должен перейти к больше логики в классе помощника и просто сопоставление моих событий непосредственно подклассу.

После ввода всего этого, я склоняюсь к последнему варианту, но я все еще разрываюсь / смущен всем этим ...

Answer 1

Страницы - это классы, и, как и любой класс, они могут стать громоздкими.Когда вы подходите к этапу, когда код тесно связан, это зависит от того, как эта связь показывает, следует ли вам проводить рефакторинг.Если код ясен, лаконичен и легок в использовании, можно оставить все как есть.Но если за ним трудно следовать, если вы не можете объяснить это коллеге в течение нескольких минут, или вы думаете, что сами не поймете это через полгода, чем это имеет право на рефакторинг.

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

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

Answer 2

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

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