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

Question

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

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

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

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

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

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

---

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

Различные пути

один путь

Answer 1

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

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

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

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

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

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

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

EDIT. - -

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

Answer 2

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

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

Answer 3

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

Answer 4

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

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