Summary prepared by Kirk Scott

Slides:



Advertisements
Similar presentations
CS 350 – Software Design The Bridge Pattern – Chapter 10 Most powerful pattern so far. Gang of Four Definition: Decouple an abstraction from its implementation.
Advertisements

Composition CMSC 202. Code Reuse Effective software development relies on reusing existing code. Code reuse must be more than just copying code and changing.
Chapter 10 THINKING IN OBJECTS 1 Object Oriented programming Instructor: Dr. Essam H. Houssein.
The Bridge Pattern.. Intent Decouple an abstraction from its implementation so that the two can vary independently Also known as: Handle/Body.
More Interfaces, Dynamic Binding, and Polymorphism Kirk Scott.
Inheritance and Class Hierarchies Chapter 3. Chapter 3: Inheritance and Class Hierarchies2 Chapter Objectives To understand inheritance and how it facilitates.
Design Patterns in Java Appendix D UML at a Glance Summary prepared by Kirk Scott 1.
CS 106 Introduction to Computer Science I 11 / 15 / 2006 Instructor: Michael Eckmann.
Aalborg Media Lab 23-Jun-15 Inheritance Lecture 10 Chapter 8.
Lecture 18 Review the difference between abstract classes and interfaces The Cloneable interface Shallow and deep copies The ActionListener interface,
Design Patterns in Java Chapter 18 Prototype Summary prepared by Kirk Scott 1.
Design Patterns in Java Chapter 21 Template Method Summary prepared by Kirk Scott 1.
Design Patterns in Java Chapter 13 Flyweight Summary prepared by Kirk Scott 1.
Recap (önemli noktaları yinelemek) from last week Paradigm Kay’s Description Intro to Objects Messages / Interconnections Information Hiding Classes Inheritance.
4.1 Instance Variables, Constructors, and Methods.
Unit 3: Java Data Types Math class and String class.
Unit 4 Prototype Summary prepared by Kirk Scott 1.
Design Patterns in Java Chapter 1 Introduction Summary prepared by Kirk Scott 1.
CSCI-383 Object-Oriented Programming & Design Lecture 13.
Chapter 2 Introducing Interfaces Summary prepared by Kirk Scott.
Unit 12 Flyweight Summary prepared by Kirk Scott 1.
Design Patterns Gang Qian Department of Computer Science University of Central Oklahoma.
Design Patterns CS 124 Reference: Gamma et al (“Gang-of-4”), Design Patterns.
Appendix D UML at a Glance Summary prepared by Kirk Scott 1.
Factory Method Explained. Intent  Define an interface for creating an object, but let subclasses decide which class to instantiate.  Factory Method.
Interfaces About Interfaces Interfaces and abstract classes provide more structured way to separate interface from implementation
Inheritance and Class Hierarchies Chapter 3. Chapter 3: Inheritance and Class Hierarchies2 Chapter Objectives To understand inheritance and how it facilitates.
Inheritance and Class Hierarchies Chapter 3. Chapter Objectives  To understand inheritance and how it facilitates code reuse  To understand how Java.
M1G Introduction to Programming 2 2. Creating Classes: Game and Player.
Memory Management.
Summary prepared by Kirk Scott
Microsoft Foundation Classes MFC
More About Objects and Methods
Summary prepared by Kirk Scott
Abstract Factory Pattern
Programming Logic and Design Seventh Edition
Phil Tayco Slide version 1.0 Created Sep 18, 2017
Design Patterns in Java Chapter 23 Strategy
Unit 11 Generic Interfaces and Encapsulation, Continued
Java Programming: Guided Learning with Early Objects
Methods Chapter 6.
Chapter 11 Object-Oriented Design
Summary prepared by Kirk Scott
Software Design and Architecture
EGR 2261 Unit 4 Control Structures I: Selection
Debugging and Random Numbers
More Interfaces, Dynamic Binding, and Polymorphism
Chapter 3: Using Methods, Classes, and Objects
Object-Oriented Programming & Design Lecture 14 Martin van Bommel
Summary prepared by Kirk Scott
Whether you decide to use hidden frames or XMLHttp, there are several things you'll need to consider when building an Ajax application. Expanding the role.
Abstract Factory Pattern
Chapter 17 Abstract Factory
Intent (Thanks to Jim Fawcett for the slides)
Phil Tayco Slide version 1.0 Created Oct 2, 2017
OOP Paradigms There are four main aspects of Object-Orientated Programming Inheritance Polymorphism Abstraction Encapsulation We’ve seen Encapsulation.
Chapter 6 Methods: A Deeper Look
Ms Munawar Khatoon IV Year I Sem Computer Science Engineering
An Introduction to Object Orientated Programming
Defining Classes and Methods
Fall 2018 CISC124 2/24/2019 CISC124 Quiz 1 marking is complete. Quiz average was about 40/60 or 67%. TAs are still grading assn 1. Assn 2 due this Friday,
Outline Anatomy of a Class Encapsulation Anatomy of a Method
Chapter 3: Selection Structures: Making Decisions
Defining Classes and Methods
Defining Classes and Methods
Review of Previous Lesson
CS 112 Programming 2 Lecture 02 Abstract Classes & Interfaces (2)
CMPE212 – Reminders Assignment 2 due next Friday.
CMSC 202 Exceptions.
HFOOAD Chapter 5 Interlude
Presentation transcript:

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