commons-io icon indicating copy to clipboard operation
commons-io copied to clipboard

Avoid Code Duplication: Reuse Sleep from ThreadMonitor

Open DaGeRe opened this issue 7 years ago • 4 comments

It makes no sense to duplicate code, like the sleep method, just to keep the interface private.

DaGeRe avatar Oct 14 '18 10:10 DaGeRe

Hi @DaGeRe !

Agree that code duplication is bad. But the change could perhaps be changed a little bit to make it easier to accept it in my opinion.

In ThreadMonitor, when you make it public, it also means that we are telling users that they are free to use this class in their code as well. Instead of it being hidden in the package level (which doesn't necessarily stops them, but discourages and at least raises the question of whether they should use it).

But I agree with the remaining changes (except by one incorrect indentation that may raise a checkstyle issue).

Would you like to try, perhaps, creating a test class in the same package, but under the test sources? That way you can either wrap or extend the origin ThreadMonitor and still remove the duplication in the sleep method. Also making it easier for us to maintain the code :-)

Cheers Bruno

kinow avatar Feb 16 '19 07:02 kinow

Hi @DaGeRe !

Agree that code duplication is bad. But the change could perhaps be changed a little bit to make it easier to accept it in my opinion.

In ThreadMonitor, when you make it public, it also means that we are telling users that they are free to use this class in their code as well. Instead of it being hidden in the package level (which doesn't necessarily stops them, but discourages and at least raises the question of whether they should use it).

But I agree with the remaining changes (except by one incorrect indentation that may raise a checkstyle issue).

Would you like to try, perhaps, creating a test class in the same package, but under the test sources? That way you can either wrap or extend the origin ThreadMonitor and still remove the duplication in the sleep method. Also making it easier for us to maintain the code :-)

Cheers Bruno

Right, this class should stay package private. You can either subclass it in the test tree as a public class or provide a public test method that accesses the package private one.

garydgregory avatar Jan 08 '21 16:01 garydgregory

@DaGeRe I've made simpler changes. Please see git master.

garydgregory avatar Sep 23 '21 18:09 garydgregory

@DaGeRe ping?

garydgregory avatar Apr 04 '22 19:04 garydgregory