月份：2006年11月

今天，添加游客评论功能设计所计划的功能已经基本实现。

1、实现过程中的改动：

  GuestArtInfo.java用原有的ArticleInfo.java代替；CookieManager.java因为所需要的代码少，另开一个类反而麻烦，功能直接写在了Action中；在util包中添加了一个处理解析存储在帖子正文头部的游客信息的工具类：GuestArtProcessor.java

2、一点心得：

  原来以为struts-config.xml中的“input="/disGoalContentAction.do"”只能用jsp文件，结果证明用*.do的路径也行，而且有时还必须如此。如下面：

自己感觉有必要写个测试列表，进行逐项测试：

1，每项功能经过游客、注册用户、管理员的测试；每项功能在日记的评论和目标的评论中都要经过测试；

2，理想状态功能使用：

填写所有字段，无无效字符串。

3，用户信息为空，或只填用户名、邮件、网址其中一项或多项；

4，帖子内容或标题为空；

5，填写了字段，但是格式错误；

6，测试在其它页面游客发的帖子是否显示正常；

7，测试有游客发帖时的邮件发送内容是否正常；

8，测试有游客发帖时的RSS订阅内容是否正常。

9，传到网上公开测试；

例外：

1，因为软件暂时没有想到解决办法或麻烦，下列项暂时搁置：

1），网址格式过滤；

2），重复提交问题；

本来，这个站根本没有朋友来回复(见：停止guest公共帐号，启用公共测试帐号)，我又怕麻烦，又想学点东西，近段时间就不打算写网站的程序了。但是，我想，万一有某个朋友有心发表点意见，一看还要注册、登录，结果想在这里留点我认为弥足珍贵的文字也打退堂鼓了。基于“不怕一万，就怕万一”的理论，万一有朋友来访，我们不能拒朋友于门外吧。

1、基本功能：

就是一般博客站的游客回复功能（如http://www.jiehoo.com， http://www.chinamyhosting.com等），具体为：

1），回复表单在显示帖子内容的下方；

2），字段包括：

名字（必须），邮件（必须），网站（可选），标题（必须，系统自动给出re:....的标题，可以修改），内容（必须）；

3），朋友在提交评论后，写入cookie，以后再次访问时不用输入除标题和内容的字段；

2，以上功能在本站实现的要点：

1），回复表单在显示帖子内容的下方：

可以参考上传文件使用的frame结构，为了简化实现，游客回复去掉上传文件功能，但可以使用UBB语法；

2），因为本站已有的数据结构和为了简化实现，所有游客的回复在系统中划为一个游客帐号的帖子；但是，为了显示上述字段，可以把上面的“名字（必须），邮件（必须），网站（可选）”字段加在内容前面，并加入特殊的分隔符，把上述字段连同内容存入数据库；要显示游客的回复的时候，把从数据库中取出的内容字段分离出“名字（必须），邮件（必须），网站（可选）”字段用于显示相关内容。

这样，在取出一篇日记或目标的评论列表，并把它们显示出来的时候，对划归游客帐号的帖子的显示格式有所变化；

3），游客发表的帖子不能被普通用户修改，但管理员可以修改和删除（例如有可能出现的垃圾信息）。

4），因为游客帐号需要保存的cookie信息没有密码，也用不着把游客的相关历史信息存入数据库。

3，具体实现：

1），jsp页面文件：只有一个显示日记或目标内容的页面需要在下部加一个游客留言的frame；

2），java文件：传递游客信息需要增加一个GuestArtInfo.java，一个相应的FormBean：GuestArtForm.java，一个提交游客评论的Action：PostGuestArtAction.java，一个游客每次提交评论成功后的cookie写入方法，可以把这个方法归入到util包，为了高效，单独建一个类CookieManager.java，方法的名字就是writeCookie(Ojbect cookieInfo)，然后，在用户以后来访问的时候，有一个读取cookie信息的方法：Object readCookie()也放在CookieManager中，同样。在这里，读了cookie还有一个传入游客评论frame页面的过程，这时，又需要建立一个保持cookie信息的GuestInfo.java

3），为了把游客的评论归入系统的单独一个游客帐户统一管理和简化实现，关健是要把“名字（必须），邮件（必须），网站（可选）”字段以特殊的标记加在内容前面，要显示时再把这些字段分离出来（日记的作者和管理员可以看见这些特殊内容），而且这个过程对用户来说是透明的。

初步设想如下：

存入数据库格式：

分离数据方式：

用正则表达式分离[guest]和[/guest]之间的内容，再用正则表达式把各个字段分离出来封装进上面保持游客cookie信息的GuestInfo.java类中。这个类的对象传入显示页面再读出来进行显示。

游客评论的显示格式为：标题  <a href=游客网站>游客名字</a> 发表时间

4、实现步骤：

1），依次完成GuestArtInfo.java，GuestInfo.java，CookieManager.java，GuestArtForm.java，PostGuestArtAction.java

2），完成jsp页面

3），测试和发布

5、时间：

想做就做，做完为止。

Thinking in Patterns with Java V0.9: chapter 10: Connecting different types: TIPatterns.htm#_Toc41169731

1, The sections name of today's learning;

Adapter. 84

Bridge. 87

Exercises. 93

2, What is it talk about in these sections and my comments and feeling for the content:

Maybe, I have gotten most feeling in this chapter. After some reading and thinking, I think I have understood these two patterns. In addition, through this chapter, I have known a little more about Proxy pattern.

1), Adapter

From my feeling, Adapter can be seen as a generlization of Proxy, and Proxy is a specific of Adapter. My understanding is below:(UML diagram is at the end of this diary)

1>, From the example: adapter:SimpleAdapter.java for Adapter and the example: proxy:ProxyDemo.java for Proxy, we can see little difference between them;

2>, From the example: adapter:AdapterVariations.java for Adapter, I haven't seen a little piece of Proxy.

Then, let us see their effects:

Proxy: fronting for another object

Adapter: Connecting different types

So, I can say in Proxy pattern: the proxy object and the implementation object these two types objects are connected by the Proxy pattern;

And, Adapter has more usage, it can unite different objects to achieve a job.

Review Bruce's words about proxy(in the end of section: Proxy: fronting for another object in chapter: Object decoupling): Of course, it isn’t necessary that Implementation have the same interface as Proxy; as long as Proxy is somehow “speaking for” the class that it is referring method calls to then the basic idea is satisfied (note that this statement is at odds with the definition for Proxy in GoF).

Then look at this statement at the end of this section: I’m taking liberties with the term “proxy” here, because in Design Patterns they assert that a proxy must have an identical interface with the object that it is a surrogate for. 

Maybe, I have found the reason of GoF's "assert that a proxy must have an identical interface with the object that it is a surrogate for. ", only in this way, Proxy pattern can be a standalone pattern in 23 patterns, otherwise, maybe it can be mixed into adaper, then, there are only 22 patterns exist now:)

And, maybe, Proxy has been used long time by people, we can't ignore its existence, it must be a standalone pattern. And, its work focuses on "fronting for other".

I can't express my entire feeling with my poor english, maybe, writing my diary in english is an error?

2), Bridge:

The most feeling in this chapter is: don't think that authority's words is all right, including GoF's. Bruce got a result after listening some other's idea about Bridge pattern, this result is: GoF's Design Patterns did "a miserable job of describing Bridge", and, there is only one place in GoF's Design Patterns is a lightspot-Bruce says continuely:"except in one place not the general structure chart describing the pattern, which wasn't helpful, but in the structure chart describing their specific example. Only if you stare at that for a bit does Bridge begin to make sense.". From this only lightspot, Bruce put up with a example of his Bridge pattern (and, maybe, is also GoF's), and, at least, I know the Bridge pattern is "often a construct that is used to help you write code. ", and it's goal is "to allow you to structure your code so that you can easily add new kinds of front-end objects which are implemented with functionality in new kinds of back-end objects."

An another meaningful statement for me is "But keep in mind that the vector of change with Bridge is typically happening at coding time: it keeps your code organized when you are dealing with an increasing number of options for implementing functionality."

Bridge pattern is a bridge between "front-end objects" and "back-end objects", regardless the number and the type of all these objects, it can provide an interface at front-end, receive all other front-end objects' requests and hand these requests to back-end interface, and it provides an interface at back-end, receive the requests which come from the front-end interface and hand these requests to back-end objects to fulfill the requests.  

3, My questions about the program itself;

1), the real application of these two patterns;

2), exercises;

4, My questions about the english language;

1), Strange words:

adaptee, take liberty with, unenlightened, begin by, conference, perspectives, give (a) talk, armed with, misinformation, delve, miserable, construct, in common, delegate, combinatorial, bookkeeping, clerking, associative, radically, Effectively

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

//: proxy:ProxyDemo.java

// Simple demonstration of the Proxy pattern.

********************************************************************

//: adapter:SimpleAdapter.java

// "Object Adapter" from GoF diagram

********************************************************************

//: adapter:AdapterVariations.java

// Variations on the Adapter pattern.

********************************************************************

//: bridge:BridgeStructure.java

// A demonstration of the structure and operation

// of the Bridge Pattern.

********************************************************************

demonstrate the structure of Bridge

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

                          incomplete

Thinking in Patterns with Java V0.9: chapter 9: too many: TIPatterns.htm#_Toc41169721

1, The sections name of today's learning;

  Flyweight: too many objects. 66

  Decorator: too many classes. 69

    Basic decorator structure. 70

    A coffee example. 70

    Class for each combination. 70

    The decorator approach. 73

    Compromise. 78

    Other considerations. 82

    Exercises. 83

2, What is it talk about in these sections and my comments and feeling for the content;

  I have never felt the design pattern's importance so strong until I read this chapter, especially the section Decorator: too many chasses.

  1), Flyweight: too many objects. 66

  For my understanding, the key of Flyweight pattern is: put all the objects of a class into one object which I named it "all_in_one", get the any object of many object from this "all_in_one" object by passing the "index" of any object of many object into this "all_in_one".

  By running the modified example in this section, I am sure it's really true.

  I modified "size = 1000000" to "size = 5000000" in flyweight:ManyObjects.java, and ran it, it reported:

The same "size = 5000000" in flyweight:FlyWeightObjects.java works well, and the running time is less much than the running time in flyweight:ManyObjects.java with "size = 1000000"( with a less size, it works.).

At the end of this section, Bruce warn us don't do a "premature optimization" by using flyweight pattern unless discovering performance bottlenecks of too many objects by using a profiler tool, I think if I haven't misunderstood his words.

2), Decorator: too many classes. 69

Just this pattern give me so strong of pattern's importance. And, the example of "coffee shop" posted by Bruce is so natural and proper. I can understand the meaning of this pattern by this example even the program detail isn't very clear for me.

For my understand, I put up another example for this pattern: "man", then decorate "man" with "good man", "wise man", "old man", "strong man", at last, a strong old wise good man appears.

Without the Decorator pattern, there will be many class need to be created in Bruce's coffee shop example.

With the Decorator pattern, there are two approachs, one is "pure" decorator, and another is compromise which mixes the approach of without decorator and with decorator.

In most real stiuations, a compromise way should be taken.

This is really a book which "Problem-Solving Techniques using Java".

The uml classes diagrams of these three approachs of solving too many classes problem which from this book is at the end of this diary.

3, My questions about the program itself;

1), "implicit this pointer in method calls, the “this index” is passed in as the first argument.", how does the implicit "this" pointer work step by step in JVM? 

4, My questions about the english language;

1), Strange words:

flyweight, odd, in the company of, hack, prohibitive, excessive, externalize, pretend, untenable, admonishment, guesswork, layered, refer to as, account for, go down to, espresso, latte, teas, whip, decaf, sizeable, Mocha, steamed, foam, conform to, mug, assembling, arduous, Compromise, present, get away, syrup, Follow the compromise approach to create a menu consisting of a Margherita, Hawaiian, Regina, and Vegetarian pizzas, with toppings (decorators) of Garlic, Olives, Spinach, Avocado, Feta and Pepperdews. Create a Hawaiian pizza, as well as a Margherita decorated with Spinach, Feta, Pepperdews and Olives. detaching, beverage

2), Strange sentences:

1>, Firstly, the combinations are fixed statically so that any combination a customer may wish to order needs to be created up front.

2>, However, the implications to the all decorator or compromise approaches are the same - one extra class is created.

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

Basic decorator structure

******************************************************************

Class for each combination

******************************************************************

The decorator approach

******************************************************************

Compromise

昨天中午，我送孩子上幼儿园。到了幼儿园门口，她非要零食吃。孩子这段时间吃零食太多了。在家里才吃了零食，所以我不准备给她买。店主在里面，我没有自己喊。孩子自己喊了几声没反应。我就开玩笑地对她说：“你看，老板不在，买不成。你想吃，自己去拿吧，看拿不拿得到？”

她站在玻璃柜台前面，往里看了又看，看玻璃柜后面。很像跃跃欲试的感觉。我一看，马上意识到我已经无意中犯了一个错误，也许还不小。就自己喊了老板给孩子买了零食吃。

这样的玩笑不能够对孩子开。孩子就像一张白纸，是没有任何对错是非观念的。你叫她去柜台里直接拿吃的，也许在她的理解就是：大人都叫我拿，这肯定是可以拿的了。如果经常反复这样，对孩子的行为习惯的塑造极为不利。

我记得自己读小学1,2年级的时候，自己还算老实吧，跟一个很调皮的孩子一起玩。然后就很自然的一起从一个缝隙钻到大伯屋里偷偷拿了大伯的钓鱼杆，这事还引起了大人之间的误会。在我当时的印象中，根本就不知道这叫作“偷窃”。

所以，我想起，有些大人爱跟小孩子开玩笑，比如，叫孩子去拿别人的东西，去打别人，去骂别人（如不雅的外号），等等。结果，在大人的哈哈大笑中，可能就给小孩的行为习惯甚至道德的培养上留下了阴影。

所以，在孩子面前开玩笑，大人们还需要三思而后行！

Thinking in Patterns with Java V0.9: chapter 8: Specialized creation: TIPatterns.htm#_Toc41169717

1, The sections name of today's learning;

Prototype. 61

Builder. 62

Exercises. 66

2, What is it talk about in these sections my comments and feeling of the content:

1), Prototype

Come up with it at this chapter, but will descript it later.

2), Builder.

"They never define exactly what they mean by representation. ", "but alas, ", etc... Again, Bruce appears to be not satisfied with the GoF's work about this part. At the end of this section, Bruce gives a simple definition of "Builder" pattern is: "Thus, Builder could be described as using a Policy to create objects."

And, maybe I have known a difference between "State" and "Builder" is: State "simply forwarding the requests" , Builder "has a sequence of operations to perform", and both "State" and "Builder" is called by a context to perform its job. At this point, maybe I have seen a little meaning of the "context" which mentioned at the begin of this book as "it will often be the controller that manages the operation of the pattern". In the example: state:StateDemo.java, the context class is "ServiceProvider", in the example: builder:BuildMedia.java, the context is "MediaDirector".

And, maybe I have also known a little of statement appeared at the section of State pattern: "State can be found everywhere because it’s such a fundamental idea. For example, in Builder, the “Director” uses a backend Builder object to produce different behaviors.".

At this point, the difference of "State", "Strategy", "Policy", "Builder" patterns make me a bit dizzy. But, I think if I read more source code of these patterns and apply these patterns in some real projects (like LearnDiary), maybe I will master these patterns really, and maybe create my own design patterns, isn't it?

3, My questions about the program;

1), Although the resulting “object” (the entire converted text file) is created over time, if you consider the conversion of each RTF directive to be an object, this feels to me a little more like Bridge, because the specific types of converters extend the interface of the base class.

2), exercises;

4, My questions about the english language;

1), Strange words:

representation, spread out, over time, essence, maze, alas, overwhelmingly, compelling, a.k.a. (Also known as.), in some ways

2), Strange sentences:

1>, The final variation of the maze builder is something that doesn’t create mazes at all, but instead counts the rooms in an existing maze.

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

UML classes diagrams of examples mentioned in this chapter:

**********************************************************************************************

//: state:StateDemo.java

// Simple demonstration of the State pattern.

*****************************************************************************************************

//: strategy:StrategyPattern.java

//Strategy: choosing the algorithm at run-time

***************************************************************************************************

//: builder:BuildMedia.java

// Example of the Builder pattern

                                                      incomplete

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.

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

Thinking in Patterns with Java V0.9: chapter 6: Factoring commonality: TIPatterns.htm#_Toc41169707

1, The sections name of today's learning;

Strategy: choosing the algorithm at run-time  48

Policy: generalized strategy. 50

Template method. 50

Exercises

2, What is it talk about in these sections and comments and feeling for the content:

  the “once and only once” principle, said at the begin of this chapter, I can't know it's meaning very clear, is it saying: do only one thing in a method?

  And, State, Strategy, Policy, Template method, it seems to me these four patterns has very similiar character, I can't distinguish them very clear.

  1), Strategy: choosing the algorithm at run-time

  However, I haven't find there is any difference bwteen State and Strategy now except their names.  class ServiceProvider in state:StateDemo.java just like class MinimaSolver in strategy:StrategyPattern.java, and so on.

  2), Policy: generalized strategy.

  No example in this section, it just says:"It also seems generally useful to distinguish Strategies with single methods from Policies with multiple methods."

  3), Template method.

  What is Template method?

  From my understanding, there exist two definitions : one is Template method Patterns; and another is a specific method in a base class, the mothod is usually called by the initialization method of this base class (I can't know if it is always called by that initialization method), this template method then call other methods in the base class to perform some actions, these performing real actions' methods can be overridden by the derived class.

  Although it says:"Note similarity with template method ? TM claims distinction that it has more than one method to call, does things piecewise. However, it?s not unlikely that strategy object would have more than one method call;" I can't feel there are too many similar places between State pattern and Template method pattern. Maybe, after reviewing this book, I will change my feeling a lot.

  I have found a bit difficult to learn this book, and write the diary in

english is a bit difficult too, if the difficult degree over my knowledge

scope a lot, maybe I will seek another resource to learn Design Patterns,

maybe a chinese book is better for me?

3, My questions about the program itself;

  1), Can't understand: Applying the "once and only once" principle produces the  most basic pattern of putting code that changes into a method.

  2), The difference between State and strategy pattern;

  3), Policy's example

  4), The difference between State and Template method.

4, My questions about the english language;

  1), Strange words:

  factoring commonality, similarity, piecewise, piecewise, shallowway, fulfullment, Policy, generalized, customs, undetermined,

  2), Strange sentences:

  1>, A fundamental concept in the application framework is the Template Method which is typically hidden beneath the covers and drives the application by calling the various methods in the base class (some of which you have overridden in order to create the application).

*****************************************************************************************************

//: strategy:StrategyPattern.java

//Strategy: choosing the algorithm at run-time

                                                      incomplete