I came across a code where a utility class has a static reference of a client of a service. Here is the simplified version of the code
public class MyHelper {
//assume that prime service checks if the number is prime
private static PrimeService client;
public static void setClient(PrimeService client) {
MyHelper.client = client;
}
public static boolean isIntegerPrime(int i) {
return client.isIntegerPrime(i);
}
}
Any thoughts on the design of this class? Apart from accidently setting the client to null, I could not think of any downside of such utility classes with static references of remote service clients. I am interested in knowing the correctness of this class from design perspective.
Your setMethod is of no use as it is not setting the static variabl.
public static void setClient(PrimeService client) {
client = client; //the assignment to this variable has no effect. }
You need to change this to
public static void setClient(PrimeService client) {
MyHelper .client = client;
}
Well, if the client is set before the 1st call of "isIntegerPrime" you would not see any NullPointerExceptions.
You might get problems with parallel access to that client. Thus when synchronization is an issue.
If PrimeService is also under your control and usage like that is ok, it might also be an option to make the method in PrimeService static.
The biggest problem you might run into with this design (aside from concurrent access and the programming error mentioned in Juned's Answer) is that you might share state inadvertently. There is no way that MyHelper can be sure that the passed client reference is not used elsewhere. This might pose an encapsulation problem. Consider the concurrent access problem. Even if you make the method isPrime(int i) synchronized, some other thread might call isIntegerPrime on the PrimeService instance passed to MyHelper.
Related
Lets say I have a Jersey-service inside a grizzles server and I like to share data between the server and the service-implementation (e.g. mydata).
public class MyServer
{
String mydata="";
public static void main (String [] args)
{
ResourceConfig rc = new ResourceConfig ().packages (MyServer.class.getPackage ().getName ());
HttpServer hs = GrizzlyHttpServerFactory.createHttpServer (URI.create ("http://localhost/myserver"), rc);
for (int i = 0; i < 10; i ++)
{
mydata += "bla";
}
hs.shutdown ();
}
}
#Path ("myservice")
public class MyService
{
#GET
public String getIt()
{
// how to access mydata?
}
}
Whats the best way to share that data?
I can think of a singleton or make mydata static. But maybe there is a standard-way I do not see here?
Thanks!
You can make mydata static or instance variable of singleton if and only if mydata is really static and cannot be changed by multiple threads (e.g. inside your getIt() method of the service).
Such technique applies and uses usually for common configuration properties.
In general it is a standard way for such situation. BTW you can keep your mydata not necessary in the Server class, but make another class to keep such common data there (if there are bunch of them) , but it is a matter of choice.
Also it is more standard to do not make actual mydata field public , but provide getter/setter pair for it.
Finally, if such common/static value can be changed by multiple threads you need to make it synchronized to avoid concurrent modifications.
There are much more different approaches to handle concurrency and make code thread-safe, but it belongs to your actual needs. Anyway all of them end up to static/singleton synchronized implementation.
PS. Be careful, if it is a common static data you have to populate it before start the server not after (as in your example) - otherwise there is a possibility that request may come before data ready to use by service thread.
Is it correct to use static method for getting instance of the Application successor in Android. I have seen this approach in a few open source projects: VLC and Shuttle
public class MyApplication extends Application {
private static MyApplication sApplication;
public static MyApplication getInstance() {
return sApplication;
}
#Override
public void onCreate() {
super.onCreate();
sApplication = MyApplication.this;
}
}
Yes. This approach is correct. This is singleton pattern you are following. As static variable is the right way always, since its the single state you want to maintain everywhere.
Also it is safe, as long as your application never runs in multiple processes. there's a strict one to one ratio of application per process.
I am also using this in my all applications.
I had difficulties finding a relevant title since it is not a simple issue. I will try to explain. I have a class responsible of error reporting whose methods basically wrap multiple ways of reporting an error.
For example, I have a method failTest:
public static void failTest(Logger log, Exception e, String message, boolean reportToES, String esTestPath, String esTestSet, String esTestInstance)
{
log.error(e, message);
someExternalErrorReportingService(reportToES, esTestPath,esTestSet,esTestInstance);
Assert.fail(e,message);
}
And I call this error reporting method in many, many places and it doesn't seem a good practice (too many parameters, hard to follow their order etc.) to just call it with the es* parameters each and every time because they don't change very often so they could be set up once and then reused.
And I came up with this version
public static void failTest(Logger log, Exception e, String message)
{//same body
}
And then added method to set up es* parameters
setES(boolean reportToES, String esTestPath, String esTestSet, String esTestInstance)
{
this.reportToES = reportToES;
this.esTestPath = esTestPath;
this.esTestSet = esTestSet;
this.esTestInstance=esTestInstance;
}
and of course added these instance variables above.
And only now I can enunciate the issue:
now if I want to use this error reporting class I need to first instantiate it and set the es* fields. The issue is that I often need to use the error reporting in a utility class that could be static but now, with my change above, I have to instantiate it and set up the error reporting class in order to have the es* fields set before I call failTest().
To conclude, I don't like this solution either because I can't use static utility classes anymore and moreover some utility classes are already used in a static way so cannot be refactored to non-static and will end up being used sometimes static, sometimes instantiated.
So the question is, do you see a better solution in order to simplify the calling of failTest() in utility classes?
To give you an example, we have a client that
sets up the error reporting class and sets up its es* fields
This client calls utility method Utility.doSomething
public static doSomething(reportToES, esTestPath, esTestSet, esTestInstance)
{
try{
methodThatThrowsFatalException()
}
catch(Exception e){
failTest(log, e, "Some smart message",reportToES, esTestPath, esTestSet, esTestInstance);
}
}
Now, in order to reduce the number of parameters we can just add setErrorReportingInstance to the Utility class,
then in client instantiate the Utility, then utilityInstance. setErrorReportingInstance(configuredErrorReportingInstance). And doSomething becomes:
public static doSomethingRefactored()
{
try{
methodThatThrowsFatalException()
}
catch(Exception e){
errorReportingInstance.failTest(log, e, "Some smart message");
}
}
What is not ok, from my point of view, is that:
1. I have complicated the usage of Utility. Now I have to make sure it is instantiated before I use it. It's inconvenient when having a lot of Utility like classes.
2. I cannot make static methods in Utility if I have to do error reporting in their implementation.
3. The methods that are already used as static will remain with the es* parameters in their signature (due to backward compatibility). So I will have in the same class methods like doSomething and also methods like doSomethingRefactored.
4. I have created a dependency between utility classes and error reporting so I have an issue when I need to test the utility methods
The question is, how can I keep the simple design of utility classes as simple collection of static utility methods but in the same time use the error reporting class but without passing too many parameters since it is bad practice?
More details:
Actually the client is many TestNG test cases:
So first I had :
class TestClass1
{
static final boolean REPORT_TO_ES="true",
static final String ES_TEST_PATH="somePath", //and so on for the others
#Test
{
Utility1.doSomething(REPORT_TO_ES,ES_TEST_PATH,ES_TEST_SET,...
Utility2.doSomethingElse(REPORT_TO_ES,ES_TEST_PATH,ES_TEST_SET,...
Utility3.doSomethingMoreUseful(REPORT_TO_ES,ES_TEST_PATH,ES_TEST_SET,...
Utility4.doSomethingSomething(REPORT_TO_ES,ES_TEST_PATH,ES_TEST_SET,...
}
And then I would try to get rid of calling the doSomethings with the ES* values
by setting them once on the ErrorReporter instance (so I would also make ErrorReporter non-static).
class TestClass1
{
private ErrorReporter errorReporter = new ErrorReporter();
errorReporter.setReportToEs(true);
errorReporter.setEsTestPath("somePath");//and so on
Utility1 utility1Instance = new Utility1();
utility1Instance.setErrorReporter(errorReporter);
Utility2 utility1Instance = new Utility2();
utility2Instance.setErrorReporter(errorReporter);
#Test
{
utility1Instance.doSomething();
utility2Instance.doSomethingElse();
...
The title to your question should be "Static Mess".
Take a look at how real loggers work and you may get some ideas. Log4J and Slf4j are well respected ones. You need to control all of your static variables. You could create a Logger class that encapsulates the ES data and does the real work of logging:
// Does the real work of logging.
class Logger {
public Logger(all of your es data)
public fail(String msg) // Logs msg
}
Then you need a static collection of these Loggers referenced by name (I assume you have more than one set of es data). This gives you a central place to go get the loggers. Works if you're in a static method or somewhere else. The static collection goes inside the LogFactory object
class LogFactory {
private static Map<String, Logger> loggers ...
public static Logger get(String name) ...
}
Here is your static method using the new logger:
public static doSomething() {
try {
methodThatThrowsFatalException()
}
catch(Exception e){
LogFactory.get("Util").failTest(e, "Some smart message");
}
}
I would add a clear or reset method to LogFactory so that you have a chance of writing JUnit tests for your code. For the same reason I would write a NullLogger (in which case you might want to pull out an interface that the NullLogger and the EsLogger can both implement.
You need to decide how to add Loggers to LogFactory. I suggest doing it in your main class. Resist the temptation to do it in a static initializer.
LogFactory could also be written so it holds a collection and not a static collection. You then just keep a static reference (a Singleton) to it. Just keep in mind that you'll want a way to clear the Singleton to make unit testing possible.
Good luck.
public class Something {
private static Something something = new Something();
public static Something get(){
return something;
}
private EventQueueWindow eventQueue;
private Something(){
TopComponent tc = WindowManager.getDefault().findTopComponent("EventQueueWindow");
eventQueue = (EventQueueWindow) tc;
}
EventQueue getQueue(){
return eventQueue;
}
}//end class Something
Now I want to write a JUnit test which requires the ability to access eventQueue.
public void testgetQueue() {
Something something = Something.get();
assertEquals("Failed to return EventQueueWindow",something.getQueue().getClass(), EventQueueWindow.class);
}
I get a java.lang.NullPointerException when I run the test because eventQueue has a null value despite it being assigned a value in class Something's constructor. I've read around that this may have something to do with components being handle in a different thread or not being initialized before the test is run. But I'm pretty new to java and unit testing and don't know how to solve this problem. Any guidance would be appreciated.
Your biggest problem is that you have global state. Global state is generally poor programming, including with tests.
Testing for particular implementation class, probably isn't a very good test.
I suggest removing your global state and dependency upon the global state that you are lumbered with from your libraries, then test that.
I believe what is going on is that the class is designed to exist inside a large context. WindowManager gives the class access to that context but the context does not exist in the unit test therefore the manager returns null.
One solution is to have two overloads of the constructor with one taking the WindowManger as an argument. Then in the test pass a mocked WindowManager to this constructor.
Mocking example via Mockito:
WindowManager man = Mockito.mock(WindowManager.class);
EventQueueWindow window = Mockito.mock(EventQueueWindow.class);
Mockito.when(man.findTopComponent("EventQueueWindow")).thenReturn(window);
This is the class that I have to test:
public class Downloader {
public String download(String uri) {
HttpClient client = this.getHttpClient();
client.setURI(uri);
return client.get();
}
private HttpClient getHttpClient() {
HttpClient client = new HttpClient();
// + some config
return client;
}
}
Very simple. Now I want to test its behavior when getHttpClient() throws an exception. However, I can't mock this method, since it is private. What is a common practice in such a situation?
I would make the HTTPClient a field of the class that is set up on construction (via a interface). Then you have the ability to create a mock HTTPClient that can throw an exception during the test if you want, e.g.:
public class Downloader {
private IHTTPClient client;
public Downloader(IHTTPClient client) {
this.client = client;
}
public String download(String uri) {
this.initialiseHttpClient();
client.setURI(uri);
return client.get();
}
private HttpClient initialiseHttpClient() {
// + some config
}
}
Then call the constructor with a real HTTPClient in production code and a Mock in the test code. You may need to create a wrapper for HTTPClient for the real code.
If you're trying to test private methods, I think something's not quite right.
You should be testing your class against its contract. The private methods are implementation-dependent, and so (in a sense) it doesn't matter what they do. You should be checking that your public methods work as expected in both functioning and non-functioning scenarios, and reflect this as appropriate back to the client (in this case, your test class).
You may need to substitute some functionality into your class for test purposes (e.g. substitute in a broken JDBC connection etc.) In that scenario I would investigate mocking and dependency injection.
It does sound a little cheesy but I generally make methods like this public and add conspicuous javadocs saying "this method is exposed public only for testing".
You can also use package-only access by having the xunit/mock etc. in the same package.
I tend to prefer using simple solutions like this as opposed to more complex and hard-to-debug techniques like AOP-style code injection.
You could make getHttpClient() protected and subclass it in the test to return what you want, so you'd have something like this in your tests:
public class TestableDownloader extends Downloader {
protected HttpClient getHttpClient() {
throw new Exception();
}
}
This isn't ideal though, you'd be better having a different design which didn't require you to test private methods (perhaps using dependency injection to provide a factory or something).
Private methods are not supposed to get a unit test. You are only supposed to unit test public methods. How a public method is organized internally does not matter to unit testing. A unit is not equal to a method. It is equal to a behavior that is possibly using more than one method to do its job.
Mocking is also a useless thing to do. If you have to mock something, your method is really integrating functions. Your code is needing refactoring to make it only do one thing and then a wrapper method calls it and the to be mocked object to integrate it.
Unit testing is something that sounds like you should do but in reality is a waste of effort that you are better to use in coding your application. Unit testing is no guarantee of better code quality and maybe it is making it worse because you are not spending enough time on your real code.