In software development, it means a set of classes that are tightly coupled: If you change one, you have to change them all, kind of thing. Usually, the classes that cooperate in a Design Pattern are tightly coupled, for example. Classes that deal with a particular common data type, is anothe example.

It may statistically correlate with “having a common function”, but this is not necessarily so. A package may have more than one interface.

The Deeplayer standard is to give packages short names. The names are used,

1. For the folder that will contain the sources in a package.
2. The namespace under which the package exists.

Only the interface(s) (header file(s), of course) are in the plain namespace. Implementations exist under a namespace “priv”, nested in the package namespace.

That which makes the classes in a package so interdependent, must therefore NOT be exposed through the interface. Otherwise the purpose of the package isn’t served.

Unlike a pattern, which has a single function and interface, a package may have multiple functions and interfaces. The only defining characteristic of a package, is tight coupling.

Unlike a dll, a package has no implied expectations of sharing, dynamic loading, or frequent updating. A package implies only an expectation of inter-correlated updates, whether frequent or not.

It is. I’m trying to identify packages in advance, but probably wasting my time. Package identification is supposed to be a discovery process, during development.