Menu
[This is not a duplicate of 23247951]
I'm maybe making too many packages, some are as deep as, for instance, mightypork.gamecore.control.events.input.
Mostly it's nice, but sometimes I'm not sure I'm doing it right. Here's an example image:
Do Tile.java and TileRenderer.java belong into tile package, because they are "top level" abstract or interfaces, or into the subpackages, because the implementations are all there? I want the structure to be logical, but this I'm really unsure about. Note, that this is just an example, I am in similar situation in at least a dozen places.
More generally, is it a good practice to make a subpackage just for concrete implementations of something?
214
You cannot put package declaration twice in the same class. The package statement must be the first line in the source file. There can be only one package statement in each source file, and it applies to all types in the file.
Naming conventions and best practices for packages The name of the package should be in small letters. It is suggested to start the name of the package with the top level domain level followed by sub domains, ex: com. example. tutorialspoint.
If you define packages try to think about modularity. Which types do address one aspect of your software making up a module with clean boundaries? Which other types define another module which do depend on other modules? Packages in Java seam to be hierarchical but they are not. Never the less, make sub-packages depend on super-packages only and never the other way around. It is ok to have sub-packages which do not depend on super-packages. And do not create technical packages like all my DAOs or all my Controllers. One major driving aspect for a package is the degree of cohesion the types inside the package do have. Another is the layering of your application.
My approach is: start by putting everything into a single package first. When your application evolves, identify the modules and repackage them. Try to keep dependencies between packages low. Check that either types of the same package do depend on each other or they address the same aspect / share related responsibilities.
68
Well. This is a view, so it might differ from person to person. Yes, its not good to put abstract classes / interfaces and concrete classes in the same package. By looking at you package, anybody should be able to say DoorTile, FloorTile etc all implement / extend Tile. So, they are grouped under the same package. And all abstract classes / interfaces can be grouped under a seperate package.
40
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
