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
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
this is a source file organization question -
I used to create separate Eclipse Projects for solutions to example problems I solved ( eg: the first one is for Exercise 1.1.2 ). Each project has a single java file with a main() function that does the work/testing. So as I keep adding new solutions the number of projects grows which is pretty unwieldy. And each project has just one java file, so there must be a better way to organize these.
What are some good ways/best practices to consolidate all these into a single project?
( Just stick the files together/ have a single main method, etc.. )
Here's what I would do. Create one project in Eclipse called "Exercises". The project should have one src folder and one test folder. Group your code into packages as suggested in another answer; com.exercises.chapterone, there either create a java class for each exercise, or one large class for each chapter with separate methods for each exercise.
Then create JUnit tests that mirror your code and run each class/method to verify that it works. You don't need a main class to run code. This will keep your workspace small and tidy and it will help you to learn how to unit test your code. This is a very important thing to learn, so the sooner you start to do it, the better.
So, something like this
Exercices
src
com.exercise.chapterone
Exercise1.java
oneOneOne(...)
oneOneTwo(...)
Exercise2.java
test
com.exercise.chapterone
TestExercise1.java
TestOneOneOne(...)
TestOneOneTwo(...)
TestExercise2.java
A place to start would to put them in one project and group them logically in packages.
E.g. you can put all 1.1 exercises in a package named com.exercises.oneone.
Firstly, you can group your exercises using packages, one exercise per package.
And then with each exercise, provide one entrance method for test, instead of a main function. And at last, you can run test using some testing libs such as junit, or you can even write a single main function to test all your exercises.
If you require independence between exercises, with junit, you can run each test case independently. While using single main function, you can pass some args into the main and determine which exercise to run.
Hope this will help you.
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