Should interfaces be placed in a separate package? [closed]

Answer 1

Put them in packages that reflect your projects. It is fine and common to put interfaces and implementations together if they're part of the same project, but if you're writing an API, then someone else would likely be choosing a package name relevant to their project.

In general, if it's for the same project, I don't see any benefit in keeping the interfaces in a separate package from their impls. If it's getting cluttered, there may be other package naming issues, irrespective of the interface arrangement.

Answer 2

The book Practical Software Engineering: A Case-Study Approach advocates for putting interfaces in seperate projects/packages.

The PCMEF+ architecture which the book talks about has the following principles:

1. Downward Dependency Principle (DDP)
2. Upward Notification Principle (UNP)
3. Neighbor Communication Principle (NCP)
4. Explicit Association Principle (EAP)
5. Cycle Elimination Principle (CEP)
6. Class Naming Principle (CNP)
7. Acquaintance Package Principle (APP)

The description of principle #3 and #7 explain why it is a good idea:

The Neighbor Communication Principle demands that a package can only communicate directly with its neighbor package. This principle ensures that the system does not disintegrate to an incompressible network of intercommunicating objects. To enforce this principle, message passing between non-neighboring objects uses delegation (Section 9.1.5.1). In more complex scenarios, acquaintance package (Section 9.1.8.2) can be used to group interfaces to assist in collaboration that engages distant packages.

The Acquaintance Package Principle is the consequence of the Neighbor Communication Principle. The acquaintance package consists of interfaces that an object passes, instead of concrete objects, in arguments to method calls. The interfaces can be implemented in any PCMEF package. This effectively allows communication between non-neighboring packages while centralizing dependency management to a single acquaintance package. The need for acquaintance package was explained in Section 9.1.8.2 and is discussed again next in PCMEF context.

See this link: http://comp.mq.edu.au/books/pse/about_book/Ch9.pdf

Answer 3

I haven't much Java experience, but I like to do this as a good practice in C#/.NET because it allows for future expansion where the assemblies with the concrete classes which implement the interfaces may not be distributed all the way down to the client because they are proxied by a middleman factory or across the wire in a web service scenario.

Answer 4

We do this where I work (ie: put interface in one package and implementation in another) and the main advantage we get out of this is we can easily swap between implementations.

Answer 5

Yes, it's a very good practice, because it allows you to publish the interface without publishing your specific implementation. That said, if you have no need to publish external interfaces, there's no problem with putting the interface definitions in the same package as the implementation.

Answer 6

In many frameworks, such as OSGi, you almost have to. I think this promotes looser coupling, at the package instead of the jar level.