This page contains a complete example of using Personalities to model a simple Zoo application. Both the Personalities/J code as well as the resulting Java code generated by PJC will be presented.

Our application domain has to do with building a software system for an animal theme park. Studying the different requirements from the distinct groups of users in the system, the software developer arrives at the object model for the animals in the theme park. The class hierarchy arrived at is shown in Figure 1.

Figure 1: The Zoo Application class hierarchy

However, the above class hierarchy only supports the needs of one of the application domains. Namely, the functions LayEggs() and Nurse(), which to some degree depend on the animal's reproductive behavior, can be correctly placed in the hierarchy. Functions that do not conform to this hierarchy, such as Swim(), Walk(), Fly(), or Jump(), cannot be placed anywhere in the hierarchy without introducing design and/or engineering errors.

Personalities are created to help in these situations. Each of the classes can personify the appropriate Personality without regard to its place in the class hierarchy. Figure 2 shows the class diagram after personalities have been introduced in the design. Now, Crocodile not only supports LayEggs() but also Swim() and Walk(). Furthermore, the implementation for Swim(), Walk(), Fly(), and Jump(), is encapsulated in one place and its semantics are fixed (provided the personifying classes abide by the LoP, of course).

The Personalities/J compiler takes a list of *.pj files and produces a set of standard Java files. The compiler generates one or more Java files per PJ file, as shown in Figure 3.

The source code shown below presents this application using both static and dynamic personalities. As such, a full set of input and output files are presented. The differences between the static and dynamic versions on the PJ code, however, are all restricted to the Zoo.pj file.