Summary prepared by Kirk Scott Unit 12 Flyweight Summary prepared by Kirk Scott
Design Patterns in Java Chapter 13 Flyweight Summary prepared by Kirk Scott
That animal is known as a couscous A trip to Wikipedia will allow you to determine whether it is related to the food named couscous…
Introduction Under the principle that responsibility is localized, when programming, typically just one object will hold a single reference to another object This is related to the idea of cloning Shallow copies with shared references are not good In general, any two objects, not necessarily clones of each other, with references to the same object may be problematic
Ideally, just one object holds a reference to another Any change to the held object will be a result of a call made in the holding object If this is the case, the holding object knows what’s been done If no other object holds a reference, no other object needs to be aware of a change
On the other hand, some objects may be referred to by many other objects Alternatively, a single object may be referred to many times by one other object Put another way, one or more clients will want to share access to the same object
Many clients/references are potentially capable of making changes to the shared object Therefore, many clients/references may have to be informed of a change The flyweight design pattern is intended to effectively manage this shared responsibility for shared objects/references
Initial Scenario The authors offer this scenario for sharing Suppose that in a text management system there is a single object for each printable character Then a book may contain thousands of references to individual instances of the character class Also, there may be many books overall, each containing multiple references to instances of the character class
In this scenario it is the individual character objects that will be implemented using the flyweight design pattern What characteristics the flyweights have and how to manage them are at the heart of the pattern
Book Definition of Pattern The intent of the Flyweight pattern is to use sharing to support large numbers of fine-grained objects efficiently. Comment mode on: Not just large numbers of objects, but potentially large numbers of references to those objects
Immutability Part of the introductory discussion mentioned the idea that if a shared object is changed, then potentially all clients should be notified Stated another way, a single action by one client can potentially affect many other clients This kind of dependence among the clients can be an undesirable kind of coupling or dependence Also, trying to notify many clients of changes can be onerous
In general, the problem can be solved by making the flyweights immutable This means that their implementation contains no method that allows them to be changed by a client
References to immutable objects may be dropped New instances with new values may be created But an existing object cannot be changed You are familiar with immutability through the Java String class
Although immutability is key to the implementation of flyweights, it’s not their only aspect (If it were, this set of overheads would not drone on at the length they do)
String Immutability, Good or Bad? Challenge 13.1 “Provide a justification of why the creators of Java made String objects immutable, or argue that this was an unwise restriction.”
Good “An argument for the immutability of strings:” This is a paraphrase of the book’s answer: Strings are frequently shared In other words, the system is supplying a class with this flyweight-like characteristic Therefore, to solve the difficulties of shared references, it was a good thing to make them into flyweights by making them immutable
Comment mode on: The immutability of strings comes up in CS 202 when discussing encapsulation and cloning The book also touches on this, but not very clearly The general rule, as presented in CS 202, is repeated very briefly here
When you have objects with instance variables that are references to objects, how should you write the get methods for them? You should probably return a clone It violates encapsulation to return a reference However, this problem is solved if the reference returned is to an immutable object So the immutability of Strings allows get methods to return references to them without violating encapsulation
Bad “An argument against the immutability of strings:” This is a paraphrase of the book’s answer: By definition, making strings immutable makes it impossible to change them This is an artificial limitation on strings that doesn’t apply to most other objects
This means Java is less flexible and contains special cases that you have to learn The authors observe that no language can completely protect the programmer from programming difficulties or making mistakes If that’s the purpose of immutability, it’s a fool’s errand
The Call of the Wild, Chapter 5 (near the end): “Thornton went on whittling. It was idle, he knew, to get between a fool and his folly; while two or three fools more or less would not alter the scheme of things.” The Java API developers struck a balance By making strings immutable, they supported simple get methods without the concern of cloning
Extracting the Immutable Part of a Flyweight With multiple references, it can be useful for a shared object to be immutable Forget the argument about the immutability of strings For the purposes of this design pattern, it is the case that the flyweight class should be immutable
This section starts with a design with lots of shared references to objects which are not flyweights The problem is that these objects are not immutable You want to refactor to a design that uses flyweights
The primary goal of refactoring is to extract the immutable part of the class that the shared references are instances of This immutable part will become a new flyweight class Other parts of the original class will have to be handled in a different way These changes in the shared references will also require changes in the application that shares them
Example The book bases its example on chemicals In a fireworks factory, the ingredients are chemical in nature In the non-flyweight design, the ingredients are referred to as substances The following UML diagram shows the substance class
The Substance class has instance variables for name, symbol, atomicWeight, and grams A digression on terminology: The instance variables symbol and atomicWeight suggest that we’re talking about chemical elements An element has a symbol and an atomic weight
For what it’s worth, the following information is given by Wikipedia: The IUPAC definition[1] of atomic weight is: An atomic weight (relative atomic mass) of an element from a specified source is the ratio of the average mass per atom of the element to 1/12 of the mass of an atom of 12C.
It becomes apparent that the authors want to refer to chemical compounds as well as elements When they refer to a symbol, they don’t just mean a single symbol for an element They also mean the chemical formula for a compound Technically, they might also have referred to molecular weight, which is the equivalent for compounds of atomic weight for elements
Distinguishing Mutable from Immutable Attributes The name, symbol, and atomicWeight instance variables of the Substance class identify and give characteristics of chemical elements and compounds They tell “what it is” For any given instance of the Substance class, these attributes would not change Depending on how the code is structured, they could become attributes of immutable objects
The instance variable gram is different Grams are a measurement of mass (what we poor benighted users of the English system think of as weight) It tells “how much there is” For any given instance of the Substance class, the value of this attribute could vary Depending on how the code is structured, this could become an attribute of mutable objects
In short, the Substance class tells both what something is and how much of it there is Such a class invites decomposition into two parts
Additional Information in the UML Diagram The UML diagram only showed get methods, but in general, the Substance class would also have set methods This is why it is mutable For what it’s worth, it also has a computed getMoles() method that returns the number of moles (6.02 x 1023 molecules, Avogadro’s number of molecules) in a given mass of an element or compound
Instances of the Mixture Class share References to Substance Objects In the fireworks scenario, there are mixtures of substances as well as substances. A mixture is a combination of chemicals which are not bound together in a single chemical compound. The next overhead shows how an instance of the Mixture class is based on having references to instances of the Substance class
In the fireworks setting there could be many different mixtures that have to be modeled There would be many references to instances of the Substance class The number of grams could differ among different instances of the substance class
The chemical compound attributes could be the same for multiple instances of the class Forget about the cosmic difficulties of mutability for a moment Notice that if there are lots of instance of Substance, there is a lot of redundancy
Refactoring the Design Challenge 13.2 “Complete the class diagram in Figure 13.3 to show a refactored Substance2 class and a new, immutable Chemical class.” Comment mode on: For a change I’m leaving this as a challenge It is worth considering the two steps: Divide the design into two classes Figure out what goes into each
Solution 13.2 “You can move the immutable aspects of Substance—including its name, symbol, and atomic weight—into the Chemical class, as Figure B.17 shows.”
Solution 13.2, continued “The Substance2 class now maintains a reference to a Chemical object. As a result, the Substance2 class can still offer the same accessors as the earlier Substance class. Internally, these accessors rely on the Chemical class, as the following Substance2 methods demonstrate.” [See the next overhead.]
public double getAtomicWeight() { return chemical.getAtomicWeight(); } public double getGrams() return grams; public double getMoles() return grams / getAtomicWeight();
Flyweight and Object Adapter You might observe that we saw code very like this in the adapter pattern, for example Informally, what has been accomplished is this: Instances of Substance2 “wrap” references to Chemicals
Substance2 provides an interface to the chemicals to the client The Substance2 interface is implemented by delegation, calling methods on the wrapped chemical object
Sharing Flyweights Extracting the immutable part of a class in order to create flyweights is one part of applying the Flyweight pattern Notice that there should only be one instance of the Chemical class for each kind of chemical Applying the pattern includes creating a “flyweight factory” This will control the construction of instances
For the the example the book proposes a ChemicalFactory class It will contain a static method that will return a reference to a chemical given the chemical’s name Internally the factory class will store the different chemicals in a hash table
You may recall that the book’s example of the mediator involved the use of a hash table It was used, among other things, to make sure there was only one reference to each tub It can also be use to make sure there is only one instance of each chemical
The UML diagram on the next overhead illustrates the relationships between the ChemicalFactory class and the Chemical class
Implementing the ChemicalFactory Class The ChemicalFactory class will only contain static things In that respect it will be like the Math class, for example There is no need to construct an instance of the class, and it doesn’t have a constructor
The ChemicalFactory class contains a static HashMap which holds instances of chemicals The empty HashMap is created using inline construction where it is declared in ChemicalFactory
The book uses what it calls a static initializer for the HashMap This is a block of code that follows the inline construction of the HashMap and constructs instances of chemicals, putting them into the HashMap Because the initializer is declared static, it is run once, when the class is loaded.
The overall purpose of the class is to make chemicals available. The class contains a static method to retrieve references to chemicals (from the hash table) and return them to callers It is called like any static method—like the methods of the Math class, for example
Partial code for the ChemicalFactory class is shown on the following overheads
import java.util.*; public class ChemicalFactory { private static Map chemicals = new HashMap(); static chemicals.put("carbon", new Chemical("Carbon", "C", 12)); chemicals.put("sulfur", new Chemical("Sulfur", "S", 32)); chemicals.put("saltpeter", new Chemical("Saltpeter", "KN03", 101)); //... } public static Chemical getChemical(String name) return (Chemical) chemicals.get(name.toLowerCase());
Static Classes and Singletons This is tangential to the flyweight pattern, but it further illuminates the singleton pattern: A singleton class would be an alternative to a class containing only static methods The static initialization code could be put into the constructor for the singleton Instead of calling static methods, you would create the one instance of the singleton and call non-static methods on that instance
Making Sure that Only One Instance of Each Chemical is Created Developers should not create their own instances of the chemical class They should only use the chemicals in the ChemicalFactory class, acquiring references by calling the getChemical() method Enforcing this discipline can be accomplished by controlling access to the Chemical class
Challenge 13.3 “How can you use the accessibility of the Chemical class to discourage other developers from instantiating Chemical objects?”
Solution 13.3 “One way that won’t work is to make the Chemical constructor private. That would prevent the ChemicalFactory class from instantiating the Chemical class” Comment mode on: This may be in the back of your mind based on having seen the singleton pattern However, it is not a solution
“To help prevent developers from instantiating the Chemical class themselves, you could place Chemical and ChemicalFactory classes in the same package and give the Chemical class’s constructor default (“package”) access.” Comment mode on: Relying on access modifiers alone is not a very strong solution
The book continues the discussion in the body of the text, following the challenge You could also prevent client code from creating instances of the Chemical class by making it an inner class of the ChemicalFactory class Keep in mind that the authors are not very good about using private access when it would be the best choice They use package or protected access when it’s convenient to them
There is confusion in the book’s presentation at this point due to their lack of discipline The text explains things in terms of a private inner class with a public constructor. But when you see their code, you discover they’ve punted by writing an inner class with no access modifier and a constructor with no access modifier (package access for both)
The discussion here will proceed under the assumption that the class is private but the constructor is public You have seen private inner classes before Recall that that was done with the inner class implementations of listeners in CS 202 If the nested class is private, then its public constructor can only be called within the code of the containing class
References to Chemical Objects Are Still Accessible in Client Code However, instances of the inner class can be accessed elsewhere Recall that you have to use a qualified name when using an inner class This line of code illustrates how the client would call the get method in the factory in order to acquire by name a reference to a desired chemical ChemicalFactory.Chemical c = ChemicalFactory.getChemical(“saltpeter”);
A More Elaborate Solution The book wants to develop its solution further Two points have been made so far 1. The flyweight should be immutable 2. It shouldn’t be possible for the client to construct instances of flyweights In this new solution, an interface will be added to the design to complete the protection of flyweights from the client
Instead of a chemical class, the design will have an interface named Chemical The Chemical interface for this enhanced solution is shown on the next overhead It simply has in it the accessor methods associated with chemicals all along
public interface Chemical { String getName(); String getSymbol(); double getAtomicWeight(); }
Then the factory class will have an inner class named ChemicalImpl, short for ChemicalImplementation The inner class, ChemicalImpl, will implement the Chemical interface Instances of ChemicalImpl will be the actual chemical objects in the application
It is a little premature, but in order to aid in explaining this, the complete UML diagram for the new design is given on the following overhead The same UML diagram will be repeated again after all of the different aspects have been discussed.
Internal to the factory, instances of ChemicalImpl are created and stored in the hash table The hash table is typed to hold interface references, Chemical The getChemical() method of the factory is typed to return interface references, Chemical ChemicalImpl objects are returned, but they are returned under the interface type
Client code is written to work with interface references of type Chemical Client code never works directly with an actual class reference to an instance of the ChemicalImpl inner class
The previous solution protected the flyweight class, Chemical, by making it an inner class This was a complete solution as long as the flyweight inner class had no dangerous methods The theory was that if it was immutable, a reference could be returned However, there is a chance that there might be other methods that you wouldn’t want client programmers to use
Using the interface, protection is ironclad Regardless of what methods might have been implemented in the inner class, the client code only has an interface reference to the chemical implementation object The client is only capable of calling methods defined in the interface, not methods defined only in the inner class
As far as the client knows, it is simply dealing with chemicals It doesn’t have to know that chemicals are created as instances of a separate, inner class known as ChemicalImpl The client code can be blissfully unaware of the existence of the flyweight inner class and contain no references to it whatsoever
This solution also has the following practical consequence on client code: The client never has to use a qualified name to refer to chemicals It refers to the chemicals by the interface name Chemical, not the inner class name
Code for the Latest Solution Challenge 13.4 Complete the following code for ChemicalFactory2.java Comment mode on: The given incomplete code is kind of long Since I always just show the answer anyway, I’m skipping the incomplete code and just going to the answer, which is on the following overheads This is the code where the authors have punted and used package access for the inner class and its constructor.
import java.util.*; public class ChemicalFactory2 { private static Map chemicals = new HashMap(); class ChemicalImpl implements Chemical private String name; private String symbol; private double atomicWeight; ChemicalImpl(String name, String symbol, double atomicWeight) this.name = name; this.symbol = symbol; this.atomicWeight = atomicWeight; }
public String getName() { return name; } public String getSymbol() return symbol; public double getAtomicWeight() return atomicWeight; public String toString() return name + "(" + symbol + ")[" + atomicWeight + "]";
static { ChemicalFactory2 factory = new ChemicalFactory2(); chemicals.put("carbon", factory.new ChemicalImpl("Carbon", "C", 12)); chemicals.put("sulfur", factory.new ChemicalImpl("Sulfur", "S", 32)); chemicals.put("saltpeter", factory.new ChemicalImpl("Saltpeter", "KN03", 101)); //... } public static Chemical getChemical(String name) return (Chemical) chemicals.get(name.toLowerCase());
UML for the Book’s Example A UML diagram that attempts to illustrate the complete book solution is given on the overhead following the next one In the diagram, only the ChemicalImpl class itself is literally the flyweight However, the use of a factory is an inherent part of the overall pattern
The Client makes use of the ChemicalFactory class to obtain references to flyweights The flyweights are needed to represent the intrinsic characteristics of chemicals References to these chemicals occur in the references to instances of the Substance class, which the client manipulates The use of the interface Chemical makes for a better implementation
Another Example Other units have had another example that was complete with a UML diagram and code The other example for this unit is merely an idea Think back to the other example for the mediator pattern It consisted of 3 cups containing 9 colored seeds
Each seed could only be in one cup at a time Now consider expanding the cups into visual representations of sets in a Venn diagram Each seed could be in (and appear in) more than one (overlapping) cup at a time This could be accomplished by cups’ sharing references to seeds
There is nothing difficult about this example It wouldn’t be hard to make the seeds immutable Also, with so few seeds, a factory would hardly seem to be necessary However, with more cups and more seeds, the flyweight design pattern might be useful
This scenario can lead to an example that tests your understanding of the pattern A simple UML class diagram is shown on the following overhead. Based only on what is in the diagram and ignoring anything else that might not be shown either in that class or in the rest of an application that used it, is the class suitable for use as a flyweight?
You could conceivably answer in two different ways: Yes, it's OK. It's immutable. The class only has get methods in it. Not, it's not OK. The getCup() method returns a reference, so it violates encapsulation and isn't really immutable.
Comparing Flyweight with Other Patterns The singleton, object adapter, and mediator patterns have come up in the discussion of flyweight This is just a brief recap of some of the connections you might draw between the patterns
Flyweight and Singleton The flyweight class isn’t a singleton There are multiple instances of a flyweight class (character, chemical, seed, for example) However, there can be no duplicate objects that are instances of the flyweight class No two instances of a flyweight should test equal for contents
A factory class is also needed for the pattern The ChemicalFactory was given as a class containing only static methods What is accomplished with a class containing static methods could be accomplished with a singleton class In essence, the factory is a kind of singleton, whether implemented that way or not
Flyweight and Object Adapter The observation here was that a client might have Substance objects which contained the mass of a quantity of a Chemical Obtaining the name of a substance’s Chemical relied on a wrapping a call to the get method on the contained flyweight reference to a Chemical
Flyweight and Mediator The flyweight factory is an important part of the application of the pattern as presented by the book The factory for flyweights has similarities with the mediator pattern The flyweight pattern depends on a factory class with a hash table containing a single column, the instances of flyweight
The factory creates the flyweights, makes sure there are no duplicates, maintains a list of them, and makes them available for sharing The flyweights have to be immutable
Lasater’s UML It is worthwhile to compare with Lasater’s take on the design The diagrams aren’t exactly the same, but if you trace through them you see that they represent the same basic idea and similar structure using slightly different notation
Lasater definitely shows a factory as part of the design Lasater doesn’t include an interface or inner class as part of the design Instead, although not so labeled, the Flyweight class appears to be abstract since it has concrete subclasses The ConcreteFlyweight seems to correspond to a substance The UnsharedConcreteFlyweight seems to correspond to a chemical
Summary The Flyweight pattern supports the sharing of one instance by many clients A flyweight class should be immutable When refactoring a design to use the flyweight pattern, part of the process is extracting the immutable part
The instances of the flyweight should be created in a factory class The factory class should also manage making the flyweights available for sharing An inner class (possibly with an interface) gives the factory a suitable level of control over the creation of instances of the flyweight A static method can be used to return references to the (immutable) flyweight objects
If the flyweight and the factory are correctly set up, you achieve these goals: Concretely, shared access is enabled This shared access is safe and foolproof Clients can’t create instances of their own
In a broader sense, the refactoring accomplishes this: You avoid a proliferation of many instances of a class that has both mutable and immutable attributes This prevents redundancy
More importantly, you avoid having shared references to classes with mutable attributes By not having shared references to mutable classes, you avoid the problem that many clients would be coupled
A change to the shared object by one of the clients would affect all of them Without the flyweight solution you would be confronted with the problem of how to notify/update all of the clients
The End