Should the interfaces be in a separate package?

Question

I am new to a team working on a fairly large project, with many components and dependencies. There is an interfaces package for each component, where the public interfaces for this component are located. Is this a good practice?

My usual practice has always been in interfaces and implementations in one package.

Answer 1

Placing both an interface and an implementation is a common place and does not seem to be a problem.

Take, for example, the Java API - most classes have both interfaces and their implementations included in the same package.

Take, for example, the java.util package:

It contains interfaces such as Set , Map , List , and also has implementations such as HashSet , HashMap and ArrayList .

In addition, Javadocs are designed to work well under these conditions, since it divides the documentation into representations of interfaces and classes when displaying package contents.

Having packages for interfaces only can be a bit overwhelming if there aren't a huge number of interfaces. But dividing interfaces into native packages just to do this sounds like bad practice.

If differentiating an interface name from an implementation is necessary, one could have a naming convention to facilitate identification of interfaces:

• Interface name prefix with I This approach is applied with interfaces in the .NET framework. It would be fairly easy to say that IList is an interface to the list.

• Use the suffix - able . This approach is often found in the Java API, for example Comparable , Iterable and Serializable , to name a few.

Answer 2

For any language, combining them into the same package is fine. The important thing is what affects the outside world and how it looks outside. No one will know or care if the implementation is implemented in the same package or not.

Let's look at this particular instance.

If you have all public items in one package and personal items in another package that is not publicly open, the library client sees one package. If you move personal items into a package with public items, but do not expose them from within the package, the client sees exactly the same thing.

Thus, it has the smell of a rule without a good reason: it makes a decision based on what is publicly available, but this decision does not affect what is openly visible.

However, if in any particular case it seems like a good idea to separate the interface and implementation into separate packages, go straight ahead and do it. The reasons for this that come to mind are that the package is huge, or you have an alternative implementation that you could bundle instead of the standard one.

Answer 3

In many frameworks, such as OSGi, you almost need to. I think it helps to grip on the packaging instead of the level of the can.

Answer 4

One argument for placing interfaces in different packages is that it’s easier to create api banks that can be distributed among consumers of your product or service. It is quite possible to do this with interfaces and implementations together, but it is easier to script if they are in different packages.

Answer 5

Yes, this is a very good practice, because it allows you to publish an interface without publishing your specific implementation. However, if you do not need to publish external interfaces, there is no problem installing the interface definitions in the same package as the implementation.

Answer 6

We do this when I work (i.e., put the interface in one package and the implementation in another), and the main advantage we get from this, we can easily swap places between implementations.

Answer 7

I have little Java experience, but I like to do this as good practice in C # /. NET, because it allows for future expansion, when assemblies with specific classes that implement interfaces may not extend all the way to the client, because they are proxied by the factory broker or through a wire in a web service script.

Answer 8

The book Practical software development: an approach to the consideration of specific cases advocates the placement of interfaces in individual projects / packages.

The PCMEF + architecture described in the book has the following principles:

• The principle of downward dependence (DDP)
• Upstream Notification Principle (UNP)
• Neighbor Communication Principle (NCP)
• Explicit Association Principle (EAP)
• Cycle Elimination Principle (CEP)
• Class Naming Principle (CNP)
• The principle of dating package (APP)

The description of principle No. 3 and No. 7 explains why this is a good idea:

The neighbor communication principle requires that a packet can directly communicate with its neighboring packet. This principle ensures that the system does not break up into an incompressible network of interacting objects. To ensure compliance with this principle, the transfer of messages between neighboring objects uses delegation (section 9.1.5.1). In more complex scenarios, a dating package (section 9.1.8.2) can be used to group interfaces to facilitate collaboration, remote packages.

The principle of the dating package is a consequence of the neighbors. The principle of communication. A dating package consists of the interfaces that an object passes, rather than specific objects, into arguments for method calls. Interfaces can be implemented in any PCMEF package. This effectively allows non-neighboring packages, while centralization of dependency management is a single package of acquaintances. The need for a package for review was explained in section 9.1.8.2 and discussed again in the PCMEF context.

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

Answer 9

I do this on a project, and it works well for me for the following reasons:

• Separately packaged interfaces and implementations are designed for a different use case than for different types of cards or sets. There is no reason to have a package for trees only (java.util.tree.Map, java.util.tree.Set). This is just a standard data structure, therefore, along with other data structures. However, if you are dealing with puzzle games that have a really simple debugging interface and a fairly production interface, you can have com.your.app.skin.debug and com.your.app.skin.pretty as part of your interface. I would not put them in the same package because they do different things, and I know that resorting to SmurfNamingConvention (DebugAttackSurface, DebugDefenceSurface, PrettyAttackSurface, etc.), to create an informal namespace for these two, if they were in one package.

• My workaround for finding related interfaces and implementations that are in separate packages is to accept the name configuration for my packages. For example. I can use all my interfaces in com.your.app.skin.framework and know that other packages on the same level of the package tree are implementations. The disadvantage is that this is an unconventional agreement. Honestly, I will see how good this agreement is in 6 months :)

• I do not use this technique religiously. There are interfaces that make sense only in a particular implementation. I do not insert them in the framework package. There are several packages where it doesn't seem like I'm going to create 40 different implementation classes, so I'm not worried.

• My application uses guice and has so many interfaces.

Program development questions are usually associated with advantages and disadvantages, and there is no answer to one size. Like, why have you ever used this technique in a tiny 200-line program? For me, this makes sense, given my other architectural solutions, for my specific problem. :)

Answer 10

Put them in packages that reflect your designs. It is very simple and convenient to combine interfaces and implementations if they are part of the same project, but if you are writing an API, then someone else will probably choose the package name that relates to their project.

In general, if it is for the same project, I do not see any benefit in supporting the interfaces in a separate package from their implants. If it becomes cluttered, other problems with package names may occur, regardless of the location of the interface.

Answer 11

I prefer them in one package. It makes no sense to create a package specifically for interfaces. This is especially tiring for teams that simply love their interface prefixes and suffixes (for example, "I" and "Impl" for Java).

If you need to publish a set of interfaces as a public API, it makes sense to save them in a completely separate project and instead create project dependencies. But it all comes down to the preference and convenience of the situation, I suppose.

Answer 12

I usually put Interfaces in an implementation, but I can understand why you might want to keep them separate. Say, for example, someone wanted to redefine classes based on your interfaces, they will need jar / lib / etc with your implementation, and not just with interfaces. With their help, you can simply say "Here is my implementation of this interface" and do with it. As I said, not what I'm doing, but I can understand why some might want to.

Answer 13

I think it’s important to note that it is better for the OSGi platform that they are in different packages, so you can easily export the whole package by hiding the implementation packages.

Answer 14

There are many good reasons for putting interfaces in a separate package from an implementation. For example, you can use a container that supports Injection of Dependency to connect the necessary implementation (s) at run time, in which case only the interface should be present at build time, and the implementation can be provided at run time. In addition, you can provide several implementations (for example, using mock for testing) or several versions of a specific implementation at run time (for example, for testing A / B, etc.). For these uses, the batch interface and implementation are more convenient.