Tag Info

New answers tagged

0

I'm too lazy to pass around a logger object to each class instance. So, in my code, these kinds of things either sit in a static field or a thread-local variable in a static field. The latter is kind of cool and lets you use a different logger for each thread and lets you add methods to turn logging on and off that do something meaningful and expected in a ...


0

It's worth mentioning, something I have not seen the other answers touch on here, is that by making the logger injected via property or static, it makes it hard(er) to unit test the class. For example, if you make your logger injected via property, you will now have to inject that logger every time you test a method that uses the logger. This means you might ...


1

I agree with those suggesting that the logger should be statically accessed rather than passed into classes. However if there is a strong reason you want to pass it in (perhaps different instances want to log to different locations or something) then I would suggest you do not pass it using the constructor but rather make a separate call to do so, e.g. ...


3

You can definitely spend a lot of time over-engineering this problem. For languages with canonical logging implementations, just instantiate the canonical logger directly in every class. For languages without a canonical implementation, try to find a logging facade framework and stick to it. slf4j is a good choice in Java. Personally I'd rather stick to a ...


26

Loggers are what we call a "cross-cutting concern." They yield to techniques such as Aspect-Oriented Programming; if you have a way to decorate your classes with an attribute or perform some code weaving, then that is a good way to get logging capabilities while keeping your objects and parameter lists "pure." The only reason you might want to pass in a ...


7

In languages with function overloading, I'd argue that the more likely an argument is to be optional, the further right it should be. This creates consistency when you create overloads where they're missing: foo(mandatory); foo(mandatory, optional); foo(mandatory, optional, evenMoreOptional); In functional languages the reverse is more useful - the more ...


2

Loggers are a bit of a special case because they have to be available literally everywhere. If you've decided that you want to pass a logger into every class' constructor, then you should definitely set a consistent convention for how you do that (eg, always the first parameter, always passed by reference, the constructor initialization list always starts ...


1

So, for me, this method does one thing. It retrieves (gets) ObjectOutputStream object as its name says No. You can't retrieve something that doesn't exist. Creating an object which didn't exist before and returning that object changes program state (possibly with other significant side effects). It's not a retrieval. Retrieval should be a safe, ...


0

As others have pointed out, your method does actually expose the fact that it is more than just a getter, since it publicizes the fact that it may throw an exception. So, you might as well make it clear in the name of the method that it works either as a getter or as a factory, otherwise someone using at it is bound to frown upon the fact that an ...


1

Yes, I think method name should describe side effects. For one thing, this example uses checked exception, which by itself reveals implementation details. Invocation of this method requires try/catch block anyway (for no reason, since it can be handled inside and throw NPE or return null, which wouldn't improve the situation, but at least make it cleaner on ...


4

Step 1 is of course make it so your method doesn't have side effects. But let's focus on the example. Yes, you should generally abstract what a function does from how it does it, but side effects are clearly still part of what the function is doing. By making them explicit in the name, you are making the code clearer about what is going on, leading to less ...


2

But you do care about it being created, because it can throw an IOException! In fact, the only time it can throw is the first time it's called. Every other time you'll need to put a pointless try/catch block (assuming this is Java) in the calling code for something that will never happen. I'd refactor this code to have an explicit stream creation method. ...



Top 50 recent answers are included