Geek Answers Handbook

Java API Design - Internal Design

I am making my first API that receives data and parses it from websites. Thus, it has a lot of network and parsing. I read about an API that has internal packages that should not be publicly available; like in Javadok. So my question is what should and should not be included in the internal package. Here is my packaging design, I leave it not important.

.networkstats .networkstats.model .networkstats.parser

Inside the networkstats package, there is a class called networkstats . This is the main class that processes and receives all network connections. Then it uses the classes inside the parser package to process the data. After that, the Model class is returned containing the data inside the model package. I want to include an internal package because there will be some classes and interfaces that are not intended for use by users.

For example, I want the class to handle all network connections so that other classes, such as networkstats , can access it. The reason I want to do this is because I don't want to copy code in other classes when it can be in one place. Of course, I do not want other users to use this class, so would I put it in an internal package? I would also put my parser package in internal. So my main question is that you put classes and interfaces that are not intended to be used in public in an internal package? I know that they can access it.

 .networkStats.internal.DataManager // class that handles network connections .networkStats.internal.parser
+7
source share
2 answers

Perhaps this Java API development checklist is helpful. The first section is about packaging design.

http://theamiableapi.com/2012/01/16/java-api-design-checklist/

Ferenc

+10
source

First of all, I would like to say that the subpackages are the same as any other package, in ordinary Java there is no such thing as private packages, if you need such a function, you will have to use OSGi

However, if you want to protect classes from access, just remove the publication from the class name and leave only the "API" classes public, these are the classes that your users will access (by invoking developers who use the framework).

The more packages you create, the more "private functions" you have to expose.

+3
source

More articles:


All Articles