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 6 years ago.
This post was edited and submitted for review 6 months ago and failed to reopen the post:
Original close reason(s) were not resolved
Improve this question
About code organisation in packages, i have seen both tools and util used for the same purpose, ie. to contain classes that help with trivial and frequent tasks.
Example:
+ foo.util
|-- StringManipulation.java
|-- MyLogger.java
+ foo.tools
|-- InputSanitization.java
|-- IdentifyOS.java
|-- Whatever.java
From your experience, is there anything that distinguishes tools from utils?
How should such reusable code be organised?
What is the generaly accepted responsibility (historically or semantically) of both and when should I use one over the other when organizing my code.
Conversely, where should I expect to find the more specialized or on the contrary more low level code in those.
Classes within the same package usually share the same or similar functionalities, or they together achieve a set of similar functionalities. In addition, classes within the same package can access all package-private variables (i.e., those variables defined without public, protected, and private) within their package.
As for naming, while Oracle has defined a convention for java naming packages, it is developer's responsibility to have a clear naming for each package. In your case, it is better to have some descriptions to describe the utilities and tools. Here are some examples:
foo.connection.tools
foo.string.utils
In this way, users can know the tools is for connections, utils is for string manipulations.
Both "tools" and "utils" are bad names for classes/packages. It is not object oriented. It is a way of saying, "I don't know what to name this thing so I'll just give it a generic name".
What you should do is figure out what these tools/utils are really doing and name them appropriately.
Related
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'm trying to make a small crud application using swing, with Authentication features and GUI.
Can you give me the right organization and naming of my packages ??
There's no hard and fast rule, but the rule of thumb is to start with your company's domain name in reverse:
com.mycompany
Then add on the project:
com.mycompany.project
This ensures you're unlikely to have clashes between your classes and those from the libraries you depend on.
Then personally I try break things down by their functional groups, for example
com.mycompany.project.domain // contains the business domain classes
com.mycompany.project.io // contains the classes that deal with network or file-system
com.mycompany.project.persistence // contains the classes that handle persistence of the business domain classes
com.mycompany.project.ui // contains the user interface related classes
Within those packages, I might have further group but that would be very specific to the project.
The important thing is to be consistent across your project.
Short answer: One package per module/feature, possibly with sub-packages. Put closely related things together in the same package. Avoid circular dependencies between packages.
Long answer: I agree with most of this article
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 9 years ago.
Improve this question
My question is fairly simple, I haven't found a direct answer to it.
Is redundant code between two or more packages to achieve package independence considered as a good or bad practice, for instance I have two packages one does a download-and-cache , the other is for readfromserver-and-cache. while cached data and mechanism are completely different but have some common classes/methods.
Shall I create a third package which holds commons, and break package in-dependency?
Or shall I continue with two packages and will result in redundant code?
Lastly, to go deep in design and dependency, I'd appreciate it if you suggest me good material to read.
*Please note : I write in java , common code is not that much
I think that you go for creating an interface for the Cache. If the cache is not the same for both packages then common code can be in a abstract class and the individual packages can implement the rest.
Of course if the code is identical, then strip it out to its own jar.
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 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.
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 7 years ago.
Improve this question
I'd like to release an open source java library. I thought of using my last name as package name but I find that a bit weird. I'd like to use something more neutral like 'open.libname'.
Are there any recommendations on open source java package naming?
As the others said, start the package name with the reversed domain name:
Register a domain such as myproject.org and then use org.myproject.mymodule.
Or, if you don't have your own domain use the sub-domain where you host the code, e.g. if you host the code on myproject.sourceforge.net, use net.sourceforge.myproject.mymodule.
The usual recommendation is to prefix your package with the name of a domain you own in reverse order: com.mydomain.mypackage. Since you own the domain, the chances of name collisions are reduced.
Also, a better choice for the package name is something that reflects the functionality of the package, rather than your own name. What will you use when you want to release your second (and perhaps totally unrelated) library?
Where are you hosting your project? When I host a project on Google Code, for example, I tend to use com.googlecode.project-name (it seems rude to use com.google.code.project-name). I don't actually know what Google thinks about this, but it follows the example of many Sourceforge.net projects. If you have a personal/corporate domain then go ahead and use that one, of course.
This may or may not be the answer you're looking for.
The common convention is to reverse your personal/company domain name and prepend it to whatever the name of the package is.
So, if your domain is "www.feel.com" and your package name is "mypackage", then your fully qualified package name would be: com.feel.mypackage