Using Object-Oriented Patterns - Beginning Java Programming: The Object-Oriented Approach - page 585

aBook.setProperty("title", aBook.getName());
aBook.setProperty("author", "Aimee, Bart and Seppe");
aBook.setProperty("pages", 540);

System.out.println("Book title: "+aBook.getProperty("title"));
System.out.println("Book author: "+aBook.getProperty("author"));
System.out.println("Book pages: "+aBook.getProperty("pages"));
}
}

Congratulations, you've just implemented the first principle of Object-Oriented Programming
(classes and objects) in an object‐oriented manner, albeit a bit awkwardly. Your properties are cur-
rently all objects and will need to be typecast to be used in a meaningful way. It's also hard to know
which properties a certain type has (this could be fixed by adding a method returning all proper-
ties). Also, this system does not support inheritance. Again, this could also be done by getting clever
and determining that ProductType objects can have a “parent” ProductType . If a property is set to
null , a product type can then ask a parent (if set) to see if they have a value for a particular prop-
erty, which is the basics of data inheritance. You might also want to modify your ProductType class
so it works more like a real constructor, which you could do by adding the following method:

public Product createProduct(String name, double price) {
return new Product(name, price, this);
}

Which can be used like so:

Product someMusic = musicType.createProduct("A music track", 0.99);
Product aBook = bookType.createProduct("My book", 44.99);

Exciting, no? Using this pattern also has the added benefit that product types can be created and
destroyed while the program is running, without requiring that you fire up Eclipse, define some new
subclasses, compile everything, and ship it out. Just ask the users which properties the new type
should have and you're golden. You could even allow users to save a list of product type definitions
to a file, which can be loaded back in.

In fact, using this pattern, you can also go a step further than Java allows. Think about the follow-
ing ideas, for instance:
➤

Allow the type of an object to change. With normal subclassing, this would not be pos-
sible (and rightly so!). If this is allowed, this pattern is sometimes called a role pattern.
Imagine your program is managing employees who can be managers or programmers. You
might want to create Employee , Manager , and Programmer classes, the latter two subclass-
ing Employee . But what if an employee's role changes? Then modeling these concepts as a
subclass is not a good idea, and you're better off with classes for Employee , EmployeeRole
(abstract), ManagerRole (concrete subclass), and ProgrammerRole (concrete subclass), and
then adding methods to Employee to set and get its role. What if roles can be defined at run-
time as well? Then you need to resort to the type pattern explained here.

➤

Allow an object to have multiple types or roles, by keeping a list of types.

➤

Allow multiple inheritance, by allowing a type to have a list of parent types. What this means
in practice is for you to determine.