Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I soon need to implement an interface. The interface will need to provide a contract between a web service and 'n' other web services for highway traffic control. The company plans to investigate/test with a single traffic control service at first and add more later as they become available. I can define an interface that's "generic" for this single use case, but the problem is that at any point in the future, we might want to communicate with another web service that may or may not be compatible with the interface we have at that time.
I could modify the Java interface as we go to accommodate the differences in API's from third party services. This would also mean updating all implementors of the interface, too.
I would like to know if there are any patterns that would be suitable for this. Almost like "dynamically extending an interface" at run time. Or, any clever use of Java generics that would allow us to implement a single Java interface once that could be used with any/all traffic control systems.
Bottom line: When we come to communicate with any other third party services, I want as minimal effort on our side to integrate them.
Any thoughts?
If the issue is adapting different representations for the same semantics, then define your own interface containing all the semantics you need, and create an adapter layer that transforms the custom representations to yours. This is the same principle behind device drivers. A uniform client interface and multiple adapters to different devices.
If you expect to encounter "devices" (traffic control services) with wildly differing semantics, then you will have to have multiple driver types... again, exactly the same situation as the difference between block devices and character devices.
Your situation is just another example of a very well known and solved pattern :-)
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I need some guidance in designing an API wrapper for my backend APIs. I have tried to keep it as specific as possible.
Context: We have a project which supports certain file operations like edit, create, merge etc. All the services are exposed as rest APIs. Now I have to create an API wrapper over this (client library) in Java. I've been reading about DDD and trying to approach the problem using that.
As per my thinking, the core object in my project would be File, along with some minor DTOs for talking to the backend. Edit, create, merge will be the verbs here acting on my domain object. I want to make it as easy as possible for the external developer to integrate the API. I would like the design to be something like that
For Creating a file : File.create() For editing : File.edit() Same for other operations Also, I want to have the capability of chaining operations (along the lines of fluent interfaces) for readability
For. eg. if you want to create a file and then convert it, it should be something like : File.create().convert(Required params)
My problem is each of the operation is bulky and async. I don't wanna write all the async error handling logic in the File class. Chaining the methods like above wont be easy as well if they return CompletableFuture objects, and this will be harder to maintain.
Question: What is a better way of solving this problem?
I am not looking for a spoonfed design. I just want to be guided to a design approach which fits the scenario. Feel free to point if I am understanding DDD wrong.
Very roughly: your domain model is responsible for bookkeeping. The effects on the state of the filesystem are implemented in your infrastructure layer, and you send the results back to the bookkeeper.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
What are the options to define the public interface to a library in Java.
For example I often find that things are public because another package in the library needs them (although still with a common base package, e.g. com.stackoverflow.mylib.), so they can't have the package access level, and generally people don't want massive packages (it also seems that people using Spring insist on having the separate controller/service/model/impl/etc. packages, resulting in a single "feature" being forced to span many packages, when say a given service might be a completely internal implementation detail not for external use...).
So the ideal goal is to make the Jar I provided to 3rd parties to make it clear that these things are not to be used, ideally by not having them available at all (not present in the API jar), so that it is not possible for them to use and compile with those internal objects/methods.
Even more ideally for objects there only supposed to obtain from some kind of factory (e.g. a provided Spring Bean), a way to prevent direct instantiation from their code or custom bean (which may leave some future, not yet present property uninitialised after upgrade).
The two formal ways I know of currently are:
In some projects I have worked on, there is an api package (e.g. com.stackoverflow.mylib.api), and the rule is only the contents of this package may be directly accessed by outside users.
In some other projects I have worked on, there have been some custom attributes, e.g. #PublicSDK to mark objects and methods for use by the public (and I think some extra stuff to ensure only things marked as such are in the publicly distributed javadoc and api jar).
The first thing to ask yourself is - do you really need to hide the implementation details?
The reason I say this is that there's going to be an expense involved in doing so, which depending on your circumstances may or may not be worth paying.
For example, if your API is being used by developers outside of your immediate team then it's probably worth the expense; however if it's just to hide the implementation details within you team I think it's overkill.
If the API is for use within your project then a standard where by you try to depend only on abstract types or interfaces is, imho, sufficient (and already the standard).
However, assuming you do need to hide the implementation and expose only the public API, the best way I know to do it is to produce two jars - one containing the public API and another that is the implementation of that API.
If you're using Maven or Gradle to build the project that is using your API you simply declare a compile time dependency on the API jar (artifact) and a runtime dependency on the implementation jar (artifact).
This pattern can be seen throughout the common Java APIs, the latest example being the JSON API that is implemented separately as part of Glassfish.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I just had this interesting discussion with a colleague of mine.
We have a remote interface which is 2000+ lines of code and has 100+ methods in it.
The implementation of this interface has some logic but also delegated to other interfaces that are related to a certain concern.
I argued we should also split up the remote interface based on concern.
Advantages:
- Separation of concerns
- Just create different endpoint for each interface, client developers should only use interfaces they are interested in
- No "monster interface"
- Eg. security possible per-endpoint
He opposes this, arguing:
- One remote interface is easy for the client developers
I'm wondering what the "general opinion" on this is?
Is it a good practice to create a remote facade which groups all your concerns in one endpoint?
If you think in terms of scalability and the fact that behind that interface you could end up having multiple services (at least in a SOA architecture) it is for sure worth splitting into multiple interfaces.
And let us see why:
Indeed as you pointed out you will have separation of concerns
You will have a light weight API - developers will end up using only features they need
It is easier to implement versioning - it might not be the case now but can be the case in the future
Readability and maintainability on your side - smaller interfaces make it easier to debug code and understand what each concern is supposed to do
Indeed security/authorization/authentication per endpoint or per remote interface is much easier to implement
I am sure that this list can continue but these are just a few I can think of now
And to give you one last argument - "the bigger they are the harder they fall"
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
As a newcomer in Java, and especially in JavaEE, I try to be as correct as possible in the words I use. I understand that an Interface is a series of abstract methods. On the other side, an Application Programming Interface is "a collection of prewritten packages, classes, and interfaces with their respective methods, fields and constructors". Am I wrong if I understand that API has not so much to do with Interfaces and could be called "Java Libraries" ? And that the use of the word Interface is, to say the least, confusing ?
Basically, you will face this terminology error everywhere. Library, API and Framework.
What you are asking,
Interface: In computing, an interface is a shared boundary across which two separate components of a computer system exchange information. The exchange can be between software, computer hardware, peripheral devices, humans and combinations of these.
This is by Wikipedia, This actually means, in Programming Languages like, Java, C++, Php or any other, it relates to isolating the layers from others. For example, You might need to access USB drive but for this, you won't use the core Java code, going deep into the Microprocessor or Micro-controller level. So, you will use any Java interface to achieve the same thing.
Whereas, when it comes to Application Programming Interface (API): then it is more application specific, not like Java interface which is more generic. For example, you are making an application which interacts with its own database, and you do not wish any third party application to interact with your database directly, but you want them to access your application, then you create an API for your application, which will act as a communication method for any third-party application to interact with your resources, safely, because you have exposed those methods.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
How can I publish an API with Java? In languages like C or C++ it is really quite easy because you can simply divide headers from code, but in Java this is a complete different story. So I know that there is no real way in Java you can obfuscate your code, even if you "obsfuscate" it, because it can be easily decompiled and analyzed. But if I don't simply can distribute headers to someone, what is the preferred way to publish a API in Java? I don't have special needs because I am in the beginning of the designing process so I am really dynamic and I would like to know all alternatives I have.
A clean way is to define your API purely in Java interfaces, include those into a separate API module and make implementation module depend on the API module. This does not provide the same functionality as separating C++ header files, but it is a good idea to program to interfaces anyway completely separating those from a particular implementation.
You don't need to publish your API as header files. Everything the developer needs is already in the JAR. If you want to publish documentation publish the java docs of the code.
You can obfuscate your code using a professional java obfuscator. Then it is not easily decompiled and readable. You can then publish your jars and javadocs like others have mentioned.
You could split your library into multiple jars and provide one with the classes and interfaces that form the api and another one that contains the implementations of those interfaces.
However, note that the hastle might not be worth it. Why exactly would you try and obfuscate code the users of that api would need anyways? What I mean is, that whoever would use your api would also need the implementations of the interfaces to run the application, so they'd still be able to decompile your code.
Generating an api-only jar would help with separating api and implementation though (which means you could replace the implementation or prevent accidential direct access to the implementation).