Thinking in Patterns chapter 7: Encapsulating creation

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: 

if(type.equals("Circle")) return new Circle();     if(type.equals("Square")) return new Square();

Is there any way make this example more OO?

2), Polymorphic factories.

Just like Bruce's words in this section as below:

However, it seems that much of the time you don?t need the intricacies of the polymorphic factory method, and a single static method in the base class (as shown in ShapeFactory1.java) will work fine.

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:

static {     ShapeFactory.addFactory(       "Circle", new Factory());   }

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:

return       ((ShapeFactory)factories.get(id)).create();

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.

================================================================================