Определенные функции по сравнению со многими Аргументами по сравнению с контекстно-зависимым

Я предлагаю более связные функции в отличие от суперфункций, которые могут делать все виды вещей, если суперфункция действительно не вызывается (printf был бы довольно неудобным, если бы печатал только один тип за раз). Избыточность подписи обычно не следует рассматривать как избыточный код. Технически говоря, это больше кода, но вам следует больше сосредоточиться на устранении логической избыточности в вашем коде. В результате получается код, который намного проще поддерживать с очень кратким и четко определенным поведением. Думайте об этом как об идеале, когда кажется излишним писать / использовать несколько функций.

Как вы уже упоминали, одна поразительная особенность - удобочитаемость: writeInUpperCaseAndCentered ("Foobar!") намного легче понять, чем write ("Foobar!", true, true) , хотя вы можете устранить эту проблему, используя перечисления. С другой стороны, наличие аргументов позволяет избежать таких неудобных конструкций, как:

if(foo)
  writeInUpperCaseAndCentered("Foobar!");
else if(bar)
  writeInLowerCaseAndCentered("Foobar!");
else
 ...

По моему скромному мнению, это очень сильный аргумент (не каламбур) в пользу аргументации.

Я предпочитаю аргумент.

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

Вместо использования аргумента для каждого отдельного случая (toUpper, по центру и т. Д.) Используйте структуру. Если вам нужно добавить больше случаев, вам нужно только изменить структуру:

typedef struct {
    int toUpper;
    int centered;
    // etc...
} cases;
write( char *str , cases c ){//..}

Я бы выбрал комбинацию методов 1 и 2.

Напишите метод (A), который имеет все аргументы, которые вам нужны/можете придумать прямо сейчас, и "голую" версию (B) без дополнительных аргументов. Эта версия может вызывать первый метод со значениями по умолчанию. Если ваш язык поддерживает это, добавьте аргументы по умолчанию. Я также рекомендую использовать осмысленные имена для аргументов и, по возможности, перечисления, а не магические числа или серию флагов true/false. Это значительно облегчит чтение вашего кода и позволит узнать, какие значения на самом деле передаются, без необходимости искать определение метода.

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

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

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

Одним из основных преимуществ этого является то, что я могу создавать объекты, которые определяют логические форматы вместо физических форматов. Это позволяет, например, сделать что-то вроде:

Format title = {upper_case, centered, bold};
Format body = {lower_case, left, normal};

write(title, "This is the title");
write(body, "This is some plain text");

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