1. Chapter 17 Abstract Factory
Summary prepared by Kirk Scott

5. Design Patterns in Java Chapter 17 Abstract Factory
Summary prepared by Kirk Scott

6. The Introduction Before the Introduction
The book provides several examples of abstract factory with context
This trimmed set of overheads restricts its attention to one of those examples

7. The Book’s Definition of the Pattern
Book definition:
The intent of the Abstract Factory, or Kit, is to allow creation of families of related or dependent objects.

8. Comment mode on:
Even though the pattern name includes the word abstract, the book’s examples don’t include an abstract class
Instead, the examples show a concrete superclass and a subclass of it
It would be possible to do the same thing with an abstract class and two concrete subclasses

9. Factory Method and Abstract Factory
A very large scale way of seeing what’s going on is this:
With a factory method, you wanted something that implemented an interface.
A number of classes satisfied this requirement, and the logic for deciding what to give the client was in the service code.

10. With abstract factory, there is a hierarchy of classes containing sets of overridden methods that return various objects
Each of the methods is basically a factory method
Each method will return an object that meets the requirement of the client.

11. The client may request which member of the family of classes it would like to make use of
With this choice, a set of methods becomes a available
Which kind of object comes back from a method call depends on the implementation of the method in the class that was chosen

12. Builder, Factory Method, and Abstract Factory
Abstract factory falls in a spectrum with the builder and factory method patterns.
With builder, a method call returned one kind of desired, specified object.
With factory method, a method call returned a reference to one of a set of kinds of objects back, with no control over which one.

13. With abstract factory it is possible to specify which one of a set of methods for generating objects is desired.
Those methods may be simple methods where the return type is a simple class reference.
Those methods may also be factory methods which return objects which agree with a required supertype, but which may actually be instances of a subtype.

14. Developing an Abstract Factory Example from the Credit Check Factory Method Example
The example is built on the factory method example of the previous unit
Here is a thumbnail review of the factory method example
The CreditCheckFactory has a method createCreditCheck() that returns a reference to an object that implements the CreditCheck interface
Two classes, CreditCheckOnline and CreditCheckOffline implement the interface

15. The code of the createCreditCheck() method knows which kind of object to create based on “server” code conditions
Client code will receive a reference to one of the two different kinds of objects
Client code doesn’t have to to specify or care which kind of object comes back
The UML diagram for this is given on the next overhead

17. Expanding the Example to the Abstract Factory Pattern
You may realize that you would like to apply the abstract factory pattern when several related factory methods arise in an application design
The idea is that there is a group of related objects that need to be created and you put the methods for creating them together in a common class

18. The book now adds things called billing checks and shipping checks to the credit check example
It doesn’t really explain what these things are, but it’s apparent that as checks, they are classified with credit checks

19. An intermediate UML diagram is given on the next overhead
It introduces the idea that you can start putting related things together in packages
The diagram is intermediate because it doesn’t have enough information in it to show how it illustrates the abstract factory design pattern
Specific comments on that will follow the diagram

21. In the preceding diagram there were two new classes, ShippingCheck and BillingCheck
Although they are checks of some sort, they don’t seem to be new types of credit checks
They don’t implement the CreditCheck interface

22. Not surprisingly then, the CreditCheckFactory doesn’t have a method which constructs objects of these two new classes
So the question remains, what are they exactly, and what role will they play in the abstract factory design pattern?

23. Another UML diagram is given on the following overhead
This is the book’s next step in explaining the design pattern—but it still doesn’t give the whole picture
In this diagram, the checks have become interfaces
Also, the CreditCheckFactory includes methods that return values that are of the types billing check, shipping check, and credit check

25. Review of the Contents of the Diagram
The preceding overhead was a UML diagram of the com.oozinoz.credit package, which contained these elements:
A CreditCheck interface
A CreditCheckOffline class that implements the interface
Two more interfaces, BillingCheck and ShippingCheck
A CreditCheckFactory class containing methods to create instances of each kind of check

26. Questions about the Design so Far
The diagram is clearly still not complete.
Only the CreditCheck interface has an implementing class.
There are no classes that implement the BillingCheck or ShippingCheck interfaces
The create() methods in the CreditCheckFactory have no classes which they could construct instances of

27. Also, there is just the one CreditCheckFactory
If there are to be families of methods, then there should be more than one factory class
It also turns out that the CreditCheckFactory is now misnamed
The factory class has methods for all 3 kinds of checks, not just credit checks

28. The issue also remains whether the CreditCheckFactory is a plain concrete class with subclasses
Or would it be better to make it an interface or an abstract class

29. Bringing the Example to Completion—Adding Packages
The book brings the example to completion in more or less the following way:
There will be no direct instances of the CreditCheckFactory class in the credit package
There will be other packages, one for each country, such as the U.S. or Canada

30. In these packages there will be classes that implement the interfaces in the credit package
There will also be a factory class which extends the CreditCheckFactory class in the credit package
The UML diagram on the following overhead illustrates the relationship between the credit package and the Canada package

32. The Canada package contains live classes BillingCheckCanada, ShippingCheckCanada, and CreditCheckCanadaOnline which implement the check interfaces
The package contains the CheckFactoryCanada class which extends the CreditCheckFactory class
The contents of the CheckFactoryCanada class aren’t shown in detail in this diagram
However, it will either inherit or override the methods which return either a billing check, a shipping check, or a credit check

33. Comment mode on:
I think the example would be better if the CreditCheckFactory class were abstract
I also think it would be better if that class were renamed simply CheckFactory
Billing and shipping checks don’t seem to be kinds of credit checks, but methods to create them are included in the factory

34. CreditCheckFactory only has the name it does because it was named before the example was expanded
Notice that the subclass is named CheckFactoryCanada, not CreditCheckFactoryCanada
In other words, implicitly the authors recognize that at the implementation level this is a check factory, not a credit check factory

35. Also, if you read the text closely, you’ll discover that at one point the authors refer to the CheckFactoryCanada class as a concrete factory, not an abstract factory
This suggests that they recognize that the plain CreditCheckFactory doesn’t have to be a concrete class

36. Continuing to Outline the Example
No separate package is given for the U.S., but conceptually the example is set up as if there would also be a concrete package for the U.S., analogous to the Canada package
There could also be separate packages for other countries, like Mexico, etc.

37. The original diagram is shown again on the next overhead.
Take a moment to consider what it would look like if a package for the U.S. were added to it

39. If set up as I would set it up, the plain credit package would contain an abstract CheckFactory class and the packages for specific countries would each contain a concrete check factory class that extended it

40. There is a reason that the CreditCheckOffline class in the credit package is already a concrete class that implements the CreditCheck interface
The CreditCheckOffline is going to be the same for both Canada and the U.S. and can be shared by the code for both
That can be taken care of with one implementing class in the parent package
The original factory method pattern is still at work because there are two kinds of credit check, online and offline

41. The abstract factory pattern is like a collection of factory methods
It is after the U.S. package is added to the picture that this becomes apparent
createBillingCheck() illustrates the idea
There are two kinds of billing check, Canadian and American
There are different classes for each, but they both implement the common BillingCheck interface

42. createBillingCheck() in the Canada package implementation will return something of type BillingCheck
There would also be a createBillingCheck() method in the U.S. package
It would also return an object of type BillingCheck
This creation method along with the others together form a family of methods for each country

43. There could be an additional layer of code on the server side of the example
That layer would contain if/else logic to determine whether a customer that a billing check was being run on was Canadian or American

44. In other words, there might be a method whatKindOfCustomer() in this example
That would be analogous to isAgencyUp() in the factory method example of the previous chapter
The actual kind of billing check object returned to a client would depend on the outcome of a call to whatKindOfCustomer()

45. The ultimate client code would simply be handed a reference to an object that implemented the BillingCheck interface
The client wouldn’t have to be aware or specifically request a billing check for one country or the other
Such a solution would make these abstract factory methods quite analogous to plain old factory methods, with the decision about what to return embedded on the server side.

46. However, the application overall could also be structured more like the GUI example
On the client side would be handed a reference to a customer of a certain nationality, or would itself create one
Then what kind of billing check came back would simply be determined by polymorphism when createBillingCheck() was called
The server side wouldn’t explicitly be in charge of determining exactly what was returned

47. The Implementation of the CheckFactoryCanada Class
I’m skipping this and everything else in the book up until its comments on packages.
Enough is enough…

48. Packages and Abstract Factories
The book now returns to the question of packages
What more they actually have to say about packages is contained in the next challenge

49. Challenge 17.5
Write down an argument supporting the decision to place each factory and its related classes in a separate package.
Or, argue that another approach is superior.

50. Solution 17.5
An example justification is:
Placing country-specific classes in separate packages helps our Oozinoz developers to organize our software and our development efforts.
By placing the classes for each country in a separate package, we keep country-specific packages independent of one another.

51. We can be confident, for example, that U. S
We can be confident, for example, that U.S.-specific classes have no impact on Canada-specific classes.
We can also easily add support for new countries.
For example, when we start doing business with Mexico, we can create a new package that provides the check services we need in a way that makes sense in that country.

52. This has the further advantage of letting us assign the credit
This has the further advantage of letting us assign the credit.mx package to a developer who has expertise in working with services and data from Mexico.

53. An argument against:
Although this separation is nice in theory, it’s overwrought in practice.
I’d rather have only one package with all the classes in it, at least until we expand to nine or ten countries.
Spreading these classes over multiple packages winds up causing me three or more times the configuration-management work when I need to implement a change that cuts across all these packages.

54. Comment mode on:
Eventually, as software grows, you may start to use packages
If so, you’ll have to decide how to divide them up.
When the time comes, you’ll have to make your own decision about the right approach

55. The book’s argument “against” summarizes my feelings about packages at this stage
Up through CSCE 222 and CSCE 302 there are no programming projects so complex that using packages is justified
Trying to use them just introduces an artificial level of complexity
Why, for example, Eclipse generates packages for a simple program consisting of a couple of classes is beyond me…

56. UML for the Pattern
Although not really complete, the book’s last diagram is repeated on the following overhead.
What’s missing is some indication that the factory makes use of the check classes
What’s also missing is another set of classes representing another family, for example, a set of classes for the United States, Mexico, etc.

58. The End