7

[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:

enter image description here

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?

Community
  • 1
  • 1
MightyPork
  • 18,270
  • 10
  • 79
  • 133
  • 1
    Hard to be specific but you often find deeper hierarchies than `mightypork.gamecore.control.events.input` and interface/implementations are often a source of package profusion. – Denys Séguret Apr 29 '14 at 08:27
  • Yeah, I know. Also, a better example might be `mightypork.util.math.constraints.num.caching`.. anyway, I'm asking mainly about the thing in the second part. – MightyPork Apr 29 '14 at 08:28
  • 2
    Wouldn't http://programmers.stackexchange.com/ be more suited for this question ? – Denys Séguret Apr 29 '14 at 08:28
  • thanks for the close vote, dystroy; much appreciated. Anyway, I'm asking here bcs I know java programmers are here. Not some obscure subforum like programmers.* – MightyPork Apr 29 '14 at 08:29
  • @MightyPork I didn't vote to close, for now. – Denys Séguret Apr 29 '14 at 08:32
  • 2
    I voted to close, you should know better than to ask a duplicate question. Especially one that's primarily opinion based and considered off topic in Stack Overflow. – Benjamin Gruenbaum Apr 29 '14 at 08:40

3 Answers3

10

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.

Harmlezz
  • 7,972
  • 27
  • 35
  • 2
    From the practical aspect, this sounds right... but then I will have a monster list of classes in the package explorer, whereas with nested packages it would look cleaner (but less useful?). – MightyPork Apr 29 '14 at 08:33
  • 1
    The *"while dependencies inside packages (between types) high"* part should be removed. There's no gain in having dependencies. – Denys Séguret Apr 29 '14 at 08:34
  • I changes _high_ into _exist_ to address cohesion. – Harmlezz Apr 29 '14 at 08:36
  • 1
    But this approach is not Strutured. A person shouldn't wait until it gets messy to change packages. Design starts from there. Classes / Interfaces in the same package are (and should be) tightly coupled from a functional perspective. What would be the point of having Tile, WallTile, DoorTile and TileRenderer under the same package? – TheLostMind Apr 29 '14 at 08:40
  • In my opinion the approach is structured. You will not find a package structure until you create some classes / types. When I create a class or type, I write a test first (Test First Approach). So I never `think ahead` and hence, I never know which classes / types will come up. So the packaging is the refactoring result of coding, which is a fixed part of my development process. It works now for years and very well. Hard to explain in words ... you have to see it in practice :) – Harmlezz Apr 29 '14 at 08:45
  • TDA (Test Driven Approach) is a totally different thing. It is bad to start coding without proper design.And a proper design includes - Use Case Diagrams, Sequence Diagrams and Class Diagrams at the very least. In such scenarios "lazy structuring" of packages / classes might lead to chaos. To put it simply : It is always better to know where to put what. – TheLostMind Apr 29 '14 at 12:57
  • I have to disagree completely, but it does not matter. As long as your approach and code work for you, continue doing it. The same is true for the code I write and I do not have Use Case Diagrams at all, no Sequence Diagrams or Class Diagrams. Things I did before but dropped doing very soon. Not very helpful except for later documentation. – Harmlezz Apr 29 '14 at 13:06
1

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.

TheLostMind
  • 35,966
  • 12
  • 68
  • 104
1

More generally, is it a good practice to make a subpackage just for concrete implementations of something?

IMO, that decision depends upon how general the interface is ,ie is it possible and very likely that you will write a different implementation of that interface ? If yes - then its better to have a separate package for these various impls - if a single default impl is sufficient then I will just put the interface and Impl together in the same package.

Bhaskar
  • 7,443
  • 5
  • 39
  • 51