1

I have a dilemma. How to do better? I have a bunch of API interfaces and their implementations which use some specific frameworks/librarys which I would not like to expose. I cannot make a decision about whether to put both API interfaces and their implementation in the same package or split them up to different packages: one (or more) for the API and others for their implementation. Here is what I mean (simplified version):

Single-package:

enter image description here

Split-packages:

enter image description here

In the first case we have API and imlementation in the same package which (may) simplify access to it. But in the second case we may also split it into a different jar file which would support more "encapsulation" from a particular implementation.

Personally, I would choose splitting them up to different jar files in order to keep API in isolation from implementations.

  • 1
    Incidentally, ApiInterface is a hideous name. – Kevin Krumwiede May 11 '16 at 19:56
  • 1
    It seems like over-design. Also, API already has Interface. Application programming interface interface implantation? – Gilad Naaman May 12 '16 at 15:07
  • @GiladNaaman What do you mean? I have just a set of interfaces and their imlpementations using some specific frameworks? What's wrong? – user3663882 May 13 '16 at 15:15
2

Well, I think the best guide are the Package Principles, and more specifically the three about package cohesion (what should be grouped into packages).

  1. Reuse-release equivalence principle (REP)
  2. Common-reuse principle (CRP)
  3. Common-closure principle (CCP)

The first and the third offer some ground for splitting up the API and its implementation into different packages.

For the first (REP), it can be argued that an implementation can have a different release cycle from the API (so they should not be in the same package) For the third (CCP), I think a stronger argument can be made. Since the API, as an abstraction, is more stable than the concrete implementation, and therefore will change for different reasons than the implementation, they should not be grouped into the same package.

From the remaining principles (those of coupling) :

  1. Acyclic dependencies principle (ADP)
  2. Stable-dependencies principle (SDP)
  3. Stable-abstractions principle (SAP)

it is clear that the second and third also implicitly argue for separating the API from the implementation.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.