I have an abstract class that will have many implementors. There are, of course, many places to put abstract classes in a Java package structure. Should the abstract class be in the same package as the implementors, or should it be in an "abstract package" package, or somewhere else? Please explain why you would place it there - I'm looking for design discussion, not just what I should do in this particular case.
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
I would put it (like any other class) in the package it belongs most from it's content. That mostly - but not everytime - means, that you put it in the same package as implementing classes. Sometimes you put an abstract class in the same package as some other class using this abstract class - it's part of the API of the other class. Implementing classes could be somewhere else in that case. I never use extra packages for abstract classes or other stuff like exception-classes or so.
Why so? I prefer to use package-structure as building a system for categorizing the content of the software, instead as using it for implementation details. The abstract-class may become later a valid non-abstract-class without breaking the API. But if I have to move it's package it would break again old code. Unnessecary I think.
I was just wondering about the same thing (but for interface classes). So lets add a post to this discussion.
I have a package
In the end, I guess I'll all type related devices in the same package (i.e. all type A in
So that's it. This is another case with another reasoning behind it.