When to Create a Package

A package is created to improve the design and architecture of software. This is the single and only reason for the existence of a package. What does it mean? The software design principles help understand this.

A package should be created to accomplish one or more of the following goals:

  • encapsulation of varying parts of a project
  • decoupling and setting boundaries between various parts
  • implementing abstract and extensible data and processes
  • providing reusable and reliable functionalities
  • distributing code.

That is all about it. If a package exists, but its existence does not support at least one of the goals above, something is wrong with the design. Here are some reasons to question the package's existence:

  • if a package does not make sense without another package (in a sense that it can't be used on its own)
  • if a package is located inside another package, and can't be used outside it, and it's not an internal package
  • if use of a package leads to an import/dependency cycle.

When planning a package, the following properties of code should guide the process:

  • roles that objects in it play
  • responsibilities that the code carries
  • functionality it provides
  • behaviours of objects.

Having clarified when to create a package, and before we can next steps, it's good to think about the lifecycle of a package, and how its design and contents influence the maintenance process.