2

I'm developing a little framework (in Scala) where I want to define clean and simple interface for the users of the framework. Some of theses interfaces have to be implemented by the framework itself, but I want to hide theses implementations from the user to keep the "surface" of the framework small and simple.

My idea is to have a package "internal" inside the root package of the framework where all these internal things go in.

com/
  example/
    framework/
      internal/
        SomeImplementation.scala
        SomeInternalThing.scala
      SomethingPublic.scala
      SomeInterface.scala

Another common option is to create an "api" package for the public things, but I feel that the package path should be as short as possible for the normal user.

com/
  example/
    framework/
      api/
        SomethingPublic.scala
        SomeInterface.scala
      SomeImplementation.scala
      SomeInternalThing.scala

Another, more radical, way would be to create two separate projects: one for the public API and one for the implementation. That is essentially what is done in the Java EE world. But this could be a bit overkill in may scenario since I'm not creating an official standard.

What would you prefer and why? Do you have any other suggestions?

1 Answer 1

3

I would definately go with the "overkill" solution: have a public project for the api, and a separate project for implementation.

com/
  example/
    framework/
      api/
      implementation/

implementation of course will have a dependency on api. I see 2 advantages:

  1. It will be easy for you to keep your public api interface clean. No classes creeping into the api because ide added 'public' keywords.

  2. I found that following best practices always pays dividends in the long run. So even if you are not creating an official standard, following this practice will ensure that you have no problems when and if your framework grows in code and user base.

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