views:

116

answers:

4

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 everywhere (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!

+2  A: 

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.

Roman
Or split the helper class into two.
Charles Beattie
i wouldn't say im making it complex. just trying to see what should one prioritize or what is a good programming philosophy:) i think i solved it. i can have a File helper class and include only that one if the classes are using file functions. so there will be multiple helper classes, not one Super helper class:)
never_had_a_name
+2  A: 

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.

Space_C0wb0y
yeah i've already thought of that: i have DatabaseLog, FileLog and ScreenLog. each one writing log to their layer.
never_had_a_name
+1  A: 

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.

Justin
but then i have to recreate write_to_file function in all classes that write to a file. and if i want to change my code i have to change in all places. the logger class is dependent to iLog, LogFactory and so on. in programming you can never have a standalone class. so i think it's better to use a helper function here and just include it in the package. then all other classes can use this one too. just my thoughts, of course there is no right or wrong.
never_had_a_name
ILog is an interface correct? in which case the file logger is an implementation not a dependency. The LogFactory provides an instance of the file logger implementation, these are not dependencies. Application code is only dependent on the LogFactory (which is one use case for dependency injection) and the ILog interface. The ILog implementations should not be dependent on application code in order to be DRY. Changes to your logger may result in application code been changed and those changes breaking the application or vice verse.
Justin
That been said if you have a file handling library used in many applications your logger could be dependent on that, provided it has a stable API.But hey its all relative and what works for you is what counts.
Justin
+1  A: 

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.

jkohlhepp