СУХАЯ дилемма программирования - PullRequest
1 голос
/ 03 мая 2010

ситуация такая:

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

Я мог бы вызвать эту функцию, но тогда класс Log зависел бы от вспомогательного класса.

не плохая ли зависимость?

но если я могу позволить ему использовать вспомогательную функцию, тогда какой смысл иметь вспомогательные функции?

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

поделитесь своими мыслями и опытом!

Ответы [ 4 ]

2 голосов
/ 03 мая 2010

Зависимости не так уж плохи; им просто нужно эффективно управлять. Похоже, что у вас может быть вспомогательный класс, который несет более одной ответственности (100 методов кажутся мне много), поэтому, возможно, этот вспомогательный класс нужно разделить на несколько классов.

Другой вариант - создать интерфейс IFileWriter, в котором есть один вспомогательный метод, который вам нужен. Затем пусть вспомогательный класс реализует этот интерфейс, а логгер зависит от интерфейса, а не от конкретного вспомогательного класса. Таким образом, если у вас есть время для рефакторинга вспомогательного класса, регистратор не должен менять.

2 голосов
/ 03 мая 2010

Это также зависит от того, насколько гибким вы хотите, чтобы вы были в классе логгеров. Если вы думаете, что, возможно, когда-нибудь позже вы захотите записать вывод журнала в сеть, а не в файл, то может быть целесообразно абстрагировать процесс записи записей журнала в интерфейс (например, LogEntrySink). Затем вы можете добавить различные приемники в ваш регистратор (например, FileWriterSink). Это дает вам возможность иметь один регистратор, использующий различные методы вывода, без изменения какого-либо кода позже.

2 голосов
/ 03 мая 2010

Я думаю, вы делаете вещи более сложными, чем они есть на самом деле.

Если есть 2 или более классов, которые нуждаются в этой функции (которые сейчас в классе помощников), то пусть она будет там, с этим проблем нет.

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

какой смысл иметь вспомогательные функции?

Если у вас есть функция, которая может использоваться (и будет использоваться наверняка) многими различными классами, и эта функция не зависит от состояния вызывающего, то она может быть вспомогательной функцией. Например, математические операции (sqrt и т. Д.) Или другие средства форматирования.

1 голос
/ 03 мая 2010

Ваш класс ведения журнала должен быть полностью автономным по следующим причинам:

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

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

...