Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
How do you decide what a package name should be and what class should go into what package ?
I'm working on a project where I am constantly adding/removing classes and not really sure if I need a new package, or should add it to an existing one that im not currently aware of.
Do you follow a set of rules when creating a new package ?
How do you know if you are not duplicating package functionality ? Is this just down to familiarity with the project.
Any pointers appreciated.
I strongly discourage from organizing packages from an implementational point of view, like controllers, data, etc. I prefer grouping them by functionality, that is, feature1, feature2, etc. If a feature is reasonably complex and requires a large number of classes, then (and only then) I create subpackages like above, that is, feature1.controllers, feature1.data, etc.
Classes should do one thing (Single Responsibility Principle).
Classes that do related things should go in the same package. If you find you can more closely relate some of the classes in a package, make them a subpackage!
For example, if I had a project with these classes:
GreetingInputWindow
GreetingDatabaseObject
GreetingDatabaseConnector
I might just put them all in the greeting package. If I wanted to, I might put GreetingInputWindow in the greeting.ui package, and the other 2 into the greeting.db package.
I don't believe there are any hard and fast rules on packaging convention (though I could be wrong). Normally I break it up into
com.mycompanyname and then:
api
controllers
data (for models)
jobs (for cron jobs)
reporting
servlet
utils
If I find I have a class which does not fit into any of those, then I create a new package.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
It seems to me that there are many instances where implementation of a specific class is the same for different projects.
In Java this is true for classes like ArrayList. So there is obviously reason to reusing generic classes across different projects.
Another generic class that would be usefull would then be ArrayMatrix, but since there is no default implementation in Java I made one myself. It's generic, safe and documented.
Is it common practice to create your own implementation in a situation like this?
If not, what's the preffered way?
If it is, what's the best practice way to share the class/code between projects and organize your "library"?
This is the entire point of having libraries. The best way to share them is to put them in an artifact repository; if possible, Central and JCenter, or some company-internal repository if the libraries can't be open-sourced for some reason. Here's the intro to publishing to Central; it's a minor hassle, but I've done it myself, and it's not too difficult.
I would encourage you to make sure that an equivalent to your class isn't already available in something like Guava or Apache Commons.
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 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).
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
E.g. I have
project X
with class a.b.c.d.AbstractFoo
now I have project Y with an implementation of AbstractFoo
Is there a convention on using package names? Is there an advantage, if say, the package names are the same?
Is there a convention on using package names?
The package name of the implementation of AbstractFoo should make sense for that class, and should not necessarily be the same as the package of AbstractFoo.
I for instance often override / implement JComponent, still I wouldn't dream of writing package javax.swing in one of my source files.
Is there an advantage, if say, the package names are the same?
No, not really. There is a semantical difference though, and that is due to the default (package level) access modifier. Relying on that the package name of one project matches the package name of another project seems like a really bad idea to me though.
don't use same packages in different projects. it's easy to fall into a name collision in a future. each project should have it's own namespace so you can put both projects on the classpath without any name collision. if you have com.yourcompany.projectA.List interface i would use something like com.yourcompany.listCommons.AbstractList class. there is no standards. naming just should be readable and understandable for others
For different projects/JARs use different package names. You will save yourself and others lots of time later.
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 am splitting my project up in to packages and this is the first time I have used this, I normally just use the default package in eclipse but i read this is not the best idea.
What i was wondering is how granular do you make projects.
I have split distinct classes in to logical groups of functionality but this leaves some stragglers left over at the end in the top root of my main package. Is it ok to just leave those there or should they have their own package?
Thanks
leaves some stragglers left over at the end in the top root of my main package. Is it ok to just leave those there or should they have their own package?
If those "stragglers" contain functionality used by the other classes, it might be better to put the in a "util" subpackage. Top packages usually contain classes that serve as a central access point to a framework or API, or (in the case of an application) that contain the main method and set up everything else.
What stragglers are left? If it is some auxiliary utilities, you can create some package like yourapp.utils and put them there. Please provide a little more details.
You should think about the fact that every project consists of modules. Think about toy blocks, that you put together to form your program.
You can imagine a package as a box where you can put another boxes or classes into.
Every package should have a clear responsibility, it could contains sub-packages or classes.
I think it is a nice project structure if you have every class in a specific package, where it is assumed to be.
So If you have structured your project in well considered packages and subpackages no class should be left alone without package. Try to find a good name for a package where it will fit into.
Maybe a "utils" package or "helper" package will a good name for something like that.
Hope I could help :)
Greetings