Kernel

Almost all the functionality in the Kernel Framework is in the sub-frameworks discussed in the subsequent chapters. The Kernel package itself contains just two concepts: Libraries and Packages. These are important to define now because they are useful in discussing the functionality of all Packages. Every ChiMu package has a "Pack" class that documents the functionality of that package.

Library

A Library is a Java "Class" that never has instances, so all functionality is in static members. A Library is really not a class at all, but Java combines object (non-static) and non-object (static) functionality into a single unit of a Class. The Library throws away the object portion of this and only uses the "Class" as a unit of modularity.

Libraries do not have "methods", they have "procedures" and "functions". The distinguishing property is that method calls are bound to methods at runtime but procedures are completely bound at compile time. This is true of static members.

By default, all Libraries are suffixed with Lib to distinguish them from interfaces (no suffix) and normal classes (which are suffixed with "Class").

Package

A Package is an object that understands the functionality of a Java Package (which is not an object). This is useful for consistency (everything "should" be an object), but more importantly it provides an entity that can:

1. Document the functionality of the Package as a whole
2. Provide Package scoped Singleton objects
3. Create Objects of the Types (Interfaces) specified in the package

Of these, probably only the last might be considered strange: Why not just use the Class to create objects of that Class’s type? The reasons are:

1. A Package creation method or function can be more intelligent than a constructor can be. A Package can reuse an existing object if needed, and can branch on the creation parameters to select the appropriate class to use. Although this could also be done with a Class static method, it does not make as much sense (why branch to a different class) and does not work as well because the static functionality will be inherited by subclasses even when it is not appropriate.
2. If you expose the Class for creation, you expose the class. All the public methods are now visible even if some of them are only for intra-subsystem functionality.
3. This produces a nice separation of instance behavior (via types) of existing objects and creation behavior (via Packages or other objects) to make those objects.
4. This also produces a nice cohesion: all the creation methods of similar types can be placed together or separated (if multiple Packages are used).

Approaches

After deciding to use Package objects there are two approaches to implementing them. Either use a real singleton object that implements the Package interface or create a pseudo-singleton object via a Library (a Pack). Although ChiMu uses primarily the latter approach, we will cover the real object approach first (Package and PackageClasses).

Package

Package defines an interface that all Package objects should be able to support. Each package can add a new subtype to Package if they want to specify new functionality beyond the standard Package functionality. They could also subclass to document the Package although that would more likely be done in either the Pack or the PackageClass.

PackageClass

To implement a Package interface requires a class. PackageAbsClass provides some inheritable functionality to build the standard Package interface and can be extended to provide the rest of the functionality for your specific package. You can also use this class to manage your Singleton Package object, although we normally use a Pack to do that.

Pack (PackageLibrary)

A Pack (short for PackageLibrary) is a simplification and "cheat" for creating a Package object: use a Library to simulate a singleton object. This is far easier to use for most clients. Instead of trying to find the Singleton object ("somebody.soleKernelPack().doSomething()"), clients can directly refer to the Pack class in their code ("KernelPack.doSomething()").

The trade off is flexibility: you can not pass around the "KernelPack" library to other parts of the system for them to work with. You also can’t "alias" a Pack so either the Pack name does not collide with other Pack names (used by a particular client) or you have to refer to the Pack class using the full path name.

All Packs should be suffixed with "Pack". This documents that they are a Package Library and prevents name collisions with the normal types and classes within the package.

ChiMu Standard Approach for Packages

ChiMu code standardizes on having Packs in all Packages and only providing real Package objects when it is necessary. Documentation is placed on the Packs.

Examples

Using PackageLibs for documentation is shown in COM.chimu.kernel.KernelPack itself. Using PackageLibs to provide package functionality is shown in COM.chimu.kernel.collections.impl.CollectionsImplPack. Almost all ChiMu classes are invisible outside the package (unless they can be inherited from), so all object constructions are done through "Pack" libraries.