DRY programming dilemma

the situation is like this:

im creating a Logger class that can write to a file but the write_to_file() function is in a helper class as a static function.

i could call that function but then the Log class would be dependent to the helper class.

isn't dependency bad?

but if i can let it use a helper function then what is the point of having helper functions?

what should one prioritize here: using helper functions and have to include this helper class ev开发者_Python百科erywhere (but the other 99 methods wont be useful) or just copy and paste into the Log class (but then if i have done this 100 times and then make a change i have to change in 100 places).

share your thoughts and experience!

Dependencies aren't bad per se; they just need to be effectively managed. It sounds like you might have a helper class that has more than one responsibility (100 methods seems like a lot to me), so maybe that helper class needs to be split apart into multiple classes.

Another option is to create a IFileWriter interface which has the one helper method you need on it. Then, have the helper class implement that interface, and have the logger depend on the interface and not on the concrete helper class. That way, if you ever have the time to refactor the helper class the logger doesn't have to change.

I think you make things more complex then they really are.

If there are 2 or more classes which need that function (which in helper class now) then let it be there, there is no problem with it.

If at the moment only logger uses this function then move it to the logger class. You can always move it back if another class needs it.

what is the point of having helper functions?

If you have a function which can be used (and will be used for sure) by many different classes and this funciton doesn't depend on a caller state then it can be a helper function. Like mathematical operations (sqrt and so on) or different formatters.

It also depends on how flexible you want you logger-class to be. If you think that maybe sometime later you want to write the log-output to the network rather than a file, then it may be wise to abstract the process of writing log-entries into an interface (e.g. LogEntrySink). Then you can inject different sinks into your logger (e.g. FileWriterSink). This gives you the ability to have one logger use different output methods without changing any code later.

Your logging class should be completely standalone for the following reasons:

• reuse purposes.
• to ensure bugs in logging code do not affect any other part of the system.
• bugs in other parts of the system do not appear as logging bugs.

The last thing you want is the scenario in the last two points. So if you have a log to file logger, I suggest you do not rely on any file related classes that are part of the application code in your logger class.