I am working on a project in which I am supposed to make a client and the role of that client is to construct a url basis on input passed and make a REST call on the right server.
And they can do it in two ways, either making a synchronous call or making an asynchronous call. So now I am not sure what is the right way to do this?
Should I make an interface for this with two methods synchronous and asynchronous method and a class that will implement this Interface or should I just make a simple class with these with these two methods inside that?
What is the better approach?
I would not put both methods into the interface, just the synchronuous one.Then imagine N different implementations which really only care about getting the data. All of them can likely be wrapped into a single asynchronuous wrapper class. No need to force each implementation to reinvent the asynchronuous behaviour.
Related
I am trying to get a grasp on the concept of using interfaces for callbacks and I feel that I have a basic understanding.
I was introduced to interfaces through the example of processing data in a collection--you can iterate through a collection of Interface objects, and each element in the collection implements that Interface in its own way.
However, I am now learning that this has some limitations, including that Library classes cannot implement the methods (what others?). How do callbacks solve these limitations? (I understand how it solves the problem I described). Thanks for the help, having a tough time really grasping this.
How do callbacks solve these limitations?
They mostly don't.
We use callbacks when we have an asynchronous interaction pattern; for example, if we want to send an HTTP request without tying up our thread, then we need a callback to handle the response when it comes.
In such a situation, we're willing to put up with the awkwardness of these limitations.
(Keep in mind that none of the limitations mean "X can't be done". For example, you write that "Library classes cannot implement the methods", which is true, but it's easy to write a callback object that operates on another object. Java 8 has made this even easier than it used to be; something like (response) -> responseList.add(response) is a complete callback object that saves the response into the existing responseList.)
Trying to figure the best design for my api where all calls will take in a base form of a request. The response will be very similar for all the calls.
Some requests will inherit some properties while others will not. All the calls will funnel through the same service so the base request will be what the main service takes in.
I.e.
public Response mainServiceHandler(BaseRequest request)
My question is what are people's thoughts on an empty abstract BaseRequest vs an empty interface BaseRequest? Any advantages of one over other in terms of an api? I thought an interface would always be the best manner since it is more flexible in design but wasn't sure if it applies in this case. Not too familiar with Marker interfaces but the little I read it didn't seem to be the best solution for this or does any implementation really makes much if a difference here.
I have a Java Swing application. I want to upload information to a web endpoint, and that process will take enough time to justify spinning off the work onto another thread. I'd like to use the Swing SwingWorker paradigm to do that. I'm confused on where I should be extending the SwingWorker.
Right now I have a single class for each web endpoint, and that class stores all the data destined for that endpoint, as well as the code necessary to interface with the endpoint (housed under a method called upload()). Should these classes implement SwingWorker since all the data is there that it needs to perform its task? Or should I have a secondary class FooWorker implement SwingWorker, that will call Upload() off of an internal Site object?
If I make a secondary FooWorker class, then it seems like I have to go to some trouble to stuff references to the Site into each FooWorker object that I instantiate (one thread/worker for each web endpoint), but that the Site won't be polluted by a bunch of SwingWorker methods and code.
If I extend SwingWorker with the Site class, then I can just call .execute() directly from the EDT for each Site which is much cleaner, to me, than creating a worker for each site, and then having that worker call upload() off the site.
Just looking for opinions and ideas about which approach is better. The Site class is already fairly complicated, and I'm afraid of putting a bunch of domain unrelated stuff into it if I extend the SwingWorker class. But the FooWorker class, if I go that route, will basically just be a thin wrapper around the Site class. Is that wrapper worth the trouble of keeping the Site class focused only on its own domain methods/data?
It is always a good idea to introduce abstractions where it makes sense. In this case, I'd say it makes sense because you might end up creating several SwingWorker classes.
What you could consider is to create a single SwingWorker class called, say, SiteWorker. Then, I'd create Site interface which implements the method upload(). Each class representing a connection to a site endpoint would implement this Site interface. You could then simply have SiteWorker to deal with the Site interface instead of you having to deal with all different sorts of Site classes implementing SwingWorker.
Remember, program to interfaces and not implementations. It makes your life easier if you can just create a single SiteWorker and then concentrate on the various site implementations.
Thus, you could pass the Site instance (which would be any class implementing Site) as an argument to the SiteWorker class, which would then, in its doInBackground() method simply call the upload() method of the instance implementing Site.
Suppose I am writing a class, which is controlling third party remote server with remote calls. Each call is asynchronous, i.e. the answer for it returns into separate function.
What is the best pattern or algorithm to wrap that remote calls?
Write wrapper method for each call with callback object as last parameter?
Each wrapper method should return "Future" object to wait for result
Make listener for results which should be added to an instance
something else?
I'm not sure there's a lot of difference across the possible solutions you're suggesting above. I would recommend using existing classes and patterns as much as possible (e.g. you mention the Future class above).
One thing that may influence your solution (and that you don't mention) is whether you need to process the results in the same order as you issue the requests, and/or if you're able to process the results in parallel or whether this needs to be synchronous.
what is the better solution in my situation, how to design classes so they are not very coupled?
I have an Library (API) which provides some functionality (for example, subscribe for streaming FX prices with subscribe method). I have an API client, which tell to API which prices it want to get. API provides feedback with some interface (for example SubscriptionStatus) with methods SubscribeSuccess(Subscription) and SubscribeFailed(Subscription). In API client I have a list of active subscriptions (List<Subscription> activeSubscriptions). And I want API client only react on subscription success (just add subscription into list). In other cases - just print message to log.
What is the best way to organize relations between Subscription listener and API Client?
Options could be:
Pass API client instance to the subscription listener so it can call apiClient.addSubscription(subscription)
API client implement implement SubscriptionStatus interface and manage those events (fail, success internally: activeSubscriptions.add(subscription)). Contra: There are a lot of types of actions and every action has it's own listener.. So Api Client will be really big class.
Define own interface with one method SubscriptionSuccess(subscription) and let API client implement it?
Your option?
Any thoughts on topic are appreciated!
Thanks!
I would go option 2, with a catch. If the SubscriptionStatus interface is really really big, and you know some clients only want to implement part of that, you can provide a base empty superclass, and you let clients extend it (make it abstract to force them)
Something like BaseSubscriptionStatus that has empty implementations for all methods, and let the user override the ones it wants. Another option is to
throw UnsupportedOperationException("This method is not supported by your implementation of SubscriptionStatus. Please override it");
for each base method instead of the empty implementation.
Of course, you can keep the SubscriptionStatus interface for proper dependency injection and testability, only make BaseSubscriptionStatus implement it.
I would go with option two. This would give the end use the most flexibility and be able to respond to issues with the streaming more effectively in their situation.