What would be the best way to structure packages to avoid duplicate package names when a sub-package is repeated?

Question

Sorry for the long somewhat unclear title, couldn't think how to word the problem I'm having. So basically I have a package structure with two reasonable alternatives (as far as I can see) but both involve a repetition on the second level.

For example, my top level packages could include tcp and bluetooth and then each of those would need a sink and source sub-package; alternatively sinks and sources could be top level packages and each of those have a tcp and bluetooth sub-package. The way around I originally started down was the first example, however now I need a source and sink interface for reusability, which would be strange to put only in one sub-package and import from, say, tcp into bluetooth; however having a copy in each would be pretty terrible practice I'm sure everyone would agree!

One additional complication is that sources and sinks in my project will not be consigned purely to connection technologies, as a local playback device is also counted as a sink to a class that sends it data.

Answer 1

Do you really need sub packages for each of sources & sinks? You might be overthinking this.

In any case, if I had to vote on the matter, I would keep the sink & source for a particular protocol together, so your top level packages would reflect the protocol (ip/bluetooth/serial): as source & sink for each protocol are more to closely related each other than are various sources across several protocols.

Good abstraction suggests to us that we need to pair sources & sinks together, because otherwise we are leaving it up to the clients to do that pairing to form the bidirectional source/sink abstraction.

The common interfaces for source and sink should get their own placement in package hierarchy independent of the protocols.

So you might have an IO package, and under that some interfaces, and also under the IO package, some protocols.

One additional complication is that sources and sinks in my project will not be consigned purely to connection technologies, as a local playback device is also counted as a sink to a class that sends it data.

As per your last, you might find multiple levels of abstraction on sources & sinks (one very general, one more specific to protocols that implements the the general while adding some protocol specific things); use interfaces and place them outside of protocols and implementations.