还是关于设计模式

我的那个那个php程序,在实现了留言板,用户登陆,注册这些基本功能和并且对UI小做了一下设计后,就没有增加什么功能了.原因是敲代码的感觉很不舒服,添加功能也不知道去哪里加.
我在设计这个程序的一开始,就打算把所有东西纳入对象中去考虑.凭着我对类分工的浅显理解.我把显示层的东西放在Page类里,把需要与数据库的交互的操作通过Page类传给相关的类,然后返回给Page类再进行显示.但是对一些实现在类与类之间的分配总是让我犹豫很久.比如对一个字段的过滤究竟是应该放在Page类里,还是具体的操作类里,或者索性把它抽象出一个类?
一番了解后,我觉得这种犹豫可能是因为我对面向对象的一些原则理解的不够透彻,实在一点的说就是我的脑子里没有相关的设计模式.所以在这段时间阅读了很多和设计模式有关的材料.最开始买了经典的GOF的设计模式,确实这本书不是十分的易懂.后来看了网上一些评论后买了大话设计模式,一本国人写得head first式的书,觉得读起来比较容易明白-虽然有些例子实在让人起鸡皮疙瘩.再加上配合李建忠的C#设计模式纵横谈,有些时候有种醍醐灌顶的感觉.现在回过头再看GOF的书,原来莫名其妙的很多地方都会有新的理解 .
再看之前的代码,就明显感觉到粗糙.按面向对象的原则重构后,思路就会变得清晰.之后再增加逻辑,我想就比较容易了.
另外就学习设计模式的路径来说,对现有代码的重构我觉得也是一种很好的方式,至少就成就感方面来说比直接按照书上敲代码高的多.而且因为的出现才去寻找相关的模式会很有针对性.

设计模式

好几次总是在作品设计到一定程度时候就进行不下去,像我做得那个php的小玩意儿.就总是苦恼在逻辑越来越复杂而引起的要瞻前顾后的窘境中.这几天在翻设计模式的书,真的感觉这就是目前的瓶颈.
觉得oop本身就是一种抽象,然后在语言技巧增加的同时需要对抽象本身进行抽象,这确实是蛮搞的,不过就像GOF那本书里表达的那样,这是在之前的抽象和之后的复杂度中间的选择.
都说GOF那本书写得很难读,自己读起来确实是这样.感觉一方面是因为本身的oop设计经验不足,其次就是这本书压根就是按成为经典的套路写的,从整本书到每张都是从抽象到具体,作为参考确实不错,但是要从通读的话确实很吃力.不过在看过一些实例以后感觉会轻松很多,我在Verycd上找到了这个,虽然是Java的模式,但道理相同.