2

I am trying to develop my package structure based on features rather than layers, but am struggling to find a package name for some of the classes. I have seen people use a package name of common for classes that seem to span multiple packages, but I cant seem to find any good resources on the best way to go about deciding what should be in a common package. Do classes in common need to be used by multiple other packages/modules to be considered "common"? Is this just a package for putting classes that don't fit in anywhere else?

Any advice is greatly appreciated.

secondbreakfast
  • 237
  • 1
  • 7
  • 2
    Related, if not a duplicate: https://softwareengineering.stackexchange.com/q/339276/20756 – Blrfl Aug 28 '18 at 13:56
  • 2
    @Blrfl: I don't think that question is a duplicate. That one is about whether or not something is a good practice. This is about what to put in this library (without regard to it being a good practice). I do think this question is opinion-based though. We'll get too many different answers, or an answer that is so general that it applies to too many situations (or no situations at all). – Greg Burghardt Aug 28 '18 at 14:08
  • @GregBurghardt "We'll get too many different answers, or an answer that is so general that it applies to too many situations (or no situations at all)" seems ironic considering the question I asked :) – secondbreakfast Aug 28 '18 at 14:10
  • @GregBurghardt Despite my comment, I didn't think that it was enough of a duplicate to cast a close vote for it. – Blrfl Aug 28 '18 at 17:12

1 Answers1

0

Never have a library called Common, Global, Helper etc

The problem is that there is no limit to the number of things that you could put in it. It has no single responsibility and will grow and grow until everything is in common.

Split up your libraries as finely as possible and use a package manager to include them in other projects as required.

Naming is of course hard, but ask yourself what the class does and call it that

Ewan
  • 70,664
  • 5
  • 76
  • 161