OK to put my public interfaces into their own package

Question

Would it be OK to put my public interfaces into their own package (for my organisation only).

for example

com.example.myprogram - contains all normal code

com.example.myprogram.public - contains public accessible interfaces

com.example.myprogram.abstract - contains abstract classes

Is this a good or a bad thing to do, are there any disadvantages?

Answer 1

I can't see that as being bad practice, however you might wanna consider as an alternative organizing your stuff per logical functionality rather than syntactic definition, so that all code for a given unit of functionality interfaces/abstract classes/normal code goes in the same package. This is one of the principles of modular programming.

Said so, putting all the interfaces (but only those) in a separated package might be necessary depending on the size of the project, and might eve become almost necessary if you have a pure component based plugin architecture (so that other module know only about interfaces and the actual implementation is somehow dynamically injected).

Answer 2

Public interfaces are a formal contract between system modules or systems. Because of that, it makes sense to isolate them from the remainder of the code, to make them stand out.

For example, in a system I've worked on, all public interfaces between the server and client components of the system have been placed in a special system module (called, no surprise, "api"). This has a number of desirable effects, among which these: - semantically, you know where to look if you need any kind of information on how communication should take place - you can version the api module separately, which is especially useful when you don't want a moving target, i.e. you sign a contract to deliver an application which will support "the api v.1.1" rather than constantly playing catch while someone else changes the interface and requires you to adapt your side

That doesn't mean you shouldn't organize them further in sub-packages to distinguish what they are for. :)

In summary, you are doing the right thing by separating the interfaces from the rest of the code base, although depending on your specific needs, you might do well to take it a step further and isolate the interfaces in a separate system module.

Answer 3

I can suggest you 2 common ways:

1. If you really think that your interfaces can have more implementations in future (i.e. you're working on API) then move them to a separate module and create there special package with name 'core', for example. (com.example.myprogram.core). Implementations should be in correspondent packages (like com.example.myprogram.firstimpl).

2. If you have only 1 implementation then let all your interfaces be in com.example.myprogram package and all concrete classes in com.example.myprogram.impl package.

Answer 4

I wouldn't like this practice at all. You should group classes, both abstract and concrete, and interfaces according to functionality.

Look at the Java API as an example. Did Sun separate the Collections interfaces from implementations? No. Sun's practices aren't always the best guide, but in this case I agree.

Don't do it.