Thinking in Patterns with Java V0.9: chapter 7: Encapsulating creation: TIPatterns.htm#_Toc41169712
1, The sections name of today's learning;
simple Factory method. 53
Polymorphic factories. 55
Abstract factories. 58
Exercises. 61
2, What is it talk about in these sections and my comments and feeling for the content:
Without the deeply thinking about the content of this chapter, and maybe I
have not many experience on program, I haven't known what matters I will meet
if creating object without "factory". But, I can see what it is talking about
in this chapter.
1), simple Factory method
The key of this pattern is a static factory method in base class can create
the objects of all kinds of sub classes according to the parameter passed into
this static factory method.
From the viewpoint of OOP, this method isn't a pure OO, because there are some
condictional testing in this method like below:
|
Is there any way make this example more OO?
2), Polymorphic factories.
Just like Bruce's words in this section as below:
|
After reading the example of this pattern, I can understand the base concept
of this pattern, I rewrite the process of this example with my own words
below:
Let's start from the main method, tracking the running step of this
example:
1>, suppose ShapeFactory.createShape("Circle"), and suppose no "Circle" in the
Map "factories" in abstract class ShapeFactory, the statement
[Class.forName("factory.shapefact2.Circle");] will create a class object
of class "factory.shapefact2.Circle", so the static block in this class will
process, here is below:
|
At this point, key-value pair: "Circle", instance object of Circle's inner class Factory which is a sub class of ShapeFactory has been puted into Map "factories";
2>, then, the statement below will create a "Circle" object and return it into
the statement in main method:
|
In this way, we can add any number's new type without modifing any existed
code, even include the factory method in class ShapeFactory.
This is a real pure OO style objects creation schema just a little complex.
Maybe, I know the reason of GoF's "However, the Design Patterns book
emphasizes that the reason for the Factory Method pattern is so that different
types of factories can be subclassed from the basic factory (the above design
is mentioned as a special case)."
Maybe because GoF want come up with a pure OO factory schema, so they say that
the simple factory method is a special case of their "intricacies of the
polymorphic factory method", I think.
I feel that Bruce maybe prefer "simple factory method" than that "Polymorphic
factories" between his words. I think Bruce is a pragmatism master, if the
non-pure OO schema can resolve problem well, why to chose a more complex
implementation? just I think.
For me, if no enough reason for chosing a complex OO impelmentation, maybe I will chose that "simple factory method", at least, I can reduce many lines' coding.
3), Abstract factories
The situation of applying this pattern in my mind maybe is below:
1>, There are several scene in the application;
2>, There are several class' object involved in every scene;
3>, The several class' object's composition is defferent from one scene to
another scene;
4>, So, every scene need a specific object factory;
5>, Create an Abstract factory is used as an interface of the specific object
factory above;
I haven't understood this pattern very clearly. If I meet some situations
future like above, I will remember this "Abstract factories" and will try its application too if I haven't forgotten this book.
3, My questions about the program itself;
1), The idea is that at the point of creation of the factory object, you decide how all the objects created by that factory will be used;
2), The use of Abstract factories;
3), exercises;
4), what are there problems when creating objects in a real application without these factories pattern above?
4, My questions about the english language;
1), Strange words:
sensible, chase down, matter, likely, suspect, happen to, presumably, sophisticated, intricacies, portability, Obstacle, Puzzle,
2), Strange sentences:
1>,It happens to be the creation of the type that matters in this case rather than the use of the type (which is taken care of by polymorphism), but the effect is the same: adding a new type can cause problems.
2>, If all the code in your program must go through this factory
whenever it needs to create one of your objects, then all you must do when you
add a new object is to modify the factory.
================================================================================
Example's uml class diagram reversed by ArgoUML0.22 (need some notion for these diagram, maybe I will do it future)
--------------------------------------------------------------------------------
Example:
//: factory:shapefact1:ShapeFactory1.java
// A simple static factory method.
*******************************************************************************
Example:
//: factory:shapefact2:ShapeFactory2.java
// Polymorphic factory methods.
********************************************************************************
Example:
//: factory:Games.java
// An example of the Abstract Factory pattern.
================================================================================
