Дизайн - когда создавать новые функции?

Question

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

Я буду использовать мой текущий проект в качестве примера. У меня есть куча вкладок в форме, которые выполняют различные функции. Допустим, вкладка 1 считывает файл с определенной разметкой, вкладка 2 экспортирует файл в определенное место и т. Д. Проблема, с которой я сейчас сталкиваюсь, заключается в том, что мне нужно, чтобы эти вкладки делали что-то немного другое в зависимости от содержимого переменная. Если он содержит 1, мне может понадобиться использовать компоновку A и выполнить некоторую дополнительную конкатенацию, если он содержит 2, мне может понадобиться использовать компоновку B и не делать конкатенацию, но добавить два целочисленных поля и т. Д. Может быть более 10 кодов, которые я будет смотреть.

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

Создание индивидуального пути для каждого кода позволило бы с первого взгляда очень легко следовать моему коду, что, в свою очередь, поможет мне позже в будущем при отладке или внесении изменений. Недостатком этого является то, что я буду увеличивать объем кода, написанного путем вызова некоторых из одних и тех же функций в нескольких местах (например, шаги 3, 5 и 9 для каждого отдельного кода могут быть абсолютно одинаковыми.

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

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

---

Редактировать: я нарисовал несколько простых изображений, чтобы помочь выразить это. Коды 1/2/3 являются переменными, а линии под ними представляют пути, по которым они пойдут. Все эти шаги должны выполняться линейно в хронологическом порядке, поэтому существует функция, которая по сути просто вызывает другие функции в правильном порядке.

Разные пути

один путь

Answer 1

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

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

Меньше LOC (строк кода) не должно быть целью.Читаемость и ремонтопригодность должны быть целью.Когда вы создаете функции, имена должны быть самодокументированы.Если у вас большой блок кода, хорошо сделать что-то вроде

   function doSomethingComplicated() {
        stepOne();
        stepTwo(); 
        // and so on
   }

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

В случае, когда у вас будет много методов, которые вызывают одни и те же точные методы, вы можете использовать хороший дизайн ОО и шаблоны проектирования, чтобы минимизировать количество функций, выполняющих одно и то же.Это относится к вашему утверждению: «Недостатком является то, что я увеличу объем кода, написанного путем вызова некоторых из одних и тех же функций в нескольких местах (например, шаги 3, 5 и 9 для каждого отдельного кода могут быть точното же самое. "

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

РЕДАКТИРОВАТЬ -

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

Answer 2

Вы должны всегда ошибаться на стороне обобщения, с единственным исключением, являющимся ранним прототипированием (где пропускная способность генерирования рабочего материала в основном зависит от разработки правильных абстракций / обобщений). Сказав это, вы НИКОГДА не должны оставлять этот беспорядок не обобщенных клонированных веток за ранним этапом создания прототипа, так как это приводит к запутанному сложному обслуживанию кода (если вы делаете почти одно и то же 3 раза, и вам нужно изменить это) вы почти наверняка забудете поменять 1 из 3).

Answer 3

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

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

Answer 4

Опять же, сложно ответить на такой открытый вопрос, но я считаю, что вам не нужно жертвовать одним ради другого.

Методы ООП решают эту проблему, позволяя инкапсулировать повторно используемые частиваш код и генерировать дочерние классы для обработки специфического поведения объекта.