headfirst设计模式????? 花了一周多一点的时间看完了headfirst的设计模式。看完之后有一种恍然大悟的感觉，
headfirst设计模式
????? 花了一周多一点的时间看完了headfirst的设计模式。看完之后有一种恍然大悟的感觉，仔细想想有觉得自己好像什么也看懂。
????? 简单说下对这本书的一点感悟吧，headfirst的书比较通俗易懂，之前看了四人帮的设计模式，看一半就有一种痛不欲生的感觉，自己水平有限，看不懂，也就没在勉强自己了。
对于模式其实简单来说，就是一种解决通用问题的通用方法。有哪些问题要解决呢。
?????? 软件工程中，最大的问题也就是在需求的变更，需要不断的更新版本。很多模式就是用来解决这个问题的，如何设计，才能更好的提高代码的可扩展性。比如说迭代器，状态模式，适配器模式等等。
????? 另外的问题，在于如何让代码思路更清晰，更好的封装代码，比如说门面模式。
????? 第三个问题就是在于对问题的理解方式，这点解释起来比较困难。比如说，多次提到的针对接口编程而非针对实现编程，将不变的变化得分开封装。其实这是回到一个很原始的问题，好比在说就是一座山，小和尚看到得就是山，老和尚看到就不一样了。设计模式教会我这样去思考代码，要针对接口编程，而非实现。就是说，如果我们晚上要看书？我们该如何解决，好找到能发光的东西。对了，这就是接口，至于你是用台灯还是白炽灯还是其他灯那是具体的实现。而当今世界最赚钱的是接口了。搞硬件都知道，很多硬件公司都是买接口的。接口是什么，就是一个解决问题的方案，一种抽象的思路。比如说，软件是什么，可以给一个规范的定义，然后，某东西是不是软件就是要拿这个规范去衡量。
????? 当我想到这里的时候，第一次觉得敲代码跟现实的生活，更其他的事情有很多是相同的。这是设计模式让我学会思考的地方。
?
1 楼 化蝶自在飞 2010-04-21 有点深奥,需要点时间来理解. 2 楼 抛出异常的爱 2010-04-25 引用
花了一周多一点的时间看完了headfirst的设计模式。看完之后有一种恍然大悟的感觉，仔细想想有觉得自己好像什么也看懂。
简单说下对这本书的一点感悟吧，headfirst的书比较通俗易懂，之前看了四人帮的设计模式，看一半就有一种痛不欲生的感觉，自己水平有限，看不懂，也就没在勉强自己了。
对于模式其实简单来说，就是一种解决通用问题的通用方法。有哪些问题要解决呢。
软件工程中，最大的问题也就是在需求的变更，需要不断的更新版本。很多模式就是用来解决这个问题的，如何设计，才能更好的提高代码的可扩展性。比如说迭代器，状态模式，适配器模式等等。
另外的问题，在于如何让代码思路更清晰，更好的封装代码，比如说门面模式。
第三个问题就是在于对问题的理解方式，这点解释起来比较困难。比如说，多次提到的针对接口编程而非针对实现编程，将不变的变化得分开封装。其实这是回到一个很原始的问题，好比在说就是一座山，小和尚看到得就是山，老和尚看到就不一样了。设计模式教会我这样去思考代码，要针对接口编程，而非实现。就是说，如果我们晚上要看书？我们该如何解决，好找到能发光的东西。对了，这就是接口，至于你是用台灯还是白炽灯还是其他灯那是具体的实现。而当今世界最赚钱的是接口了。搞硬件都知道，很多硬件公司都是买接口的。接口是什么，就是一个解决问题的方案，一种抽象的思路。比如说，软件是什么，可以给一个规范的定义，然后，某东西是不是软件就是要拿这个规范去衡量。
当我想到这里的时候，第一次觉得敲代码跟现实的生活，更其他的事情有很多是相同的。这是设计模式让我学会思考的地方。
已知世界的近200种软件模式
四人帮把这些又抽象了一次。
先找到一些标准项目看看其模式应用
再考虑四人帮的模式吧 3 楼 orcl_zhang 2010-04-25 抛出异常的爱 写道引用
花了一周多一点的时间看完了headfirst的设计模式。看完之后有一种恍然大悟的感觉，仔细想想有觉得自己好像什么也看懂。
简单说下对这本书的一点感悟吧，headfirst的书比较通俗易懂，之前看了四人帮的设计模式，看一半就有一种痛不欲生的感觉，自己水平有限，看不懂，也就没在勉强自己了。
对于模式其实简单来说，就是一种解决通用问题的通用方法。有哪些问题要解决呢。
软件工程中，最大的问题也就是在需求的变更，需要不断的更新版本。很多模式就是用来解决这个问题的，如何设计，才能更好的提高代码的可扩展性。比如说迭代器，状态模式，适配器模式等等。
另外的问题，在于如何让代码思路更清晰，更好的封装代码，比如说门面模式。
第三个问题就是在于对问题的理解方式，这点解释起来比较困难。比如说，多次提到的针对接口编程而非针对实现编程，将不变的变化得分开封装。其实这是回到一个很原始的问题，好比在说就是一座山，小和尚看到得就是山，老和尚看到就不一样了。设计模式教会我这样去思考代码，要针对接口编程，而非实现。就是说，如果我们晚上要看书？我们该如何解决，好找到能发光的东西。对了，这就是接口，至于你是用台灯还是白炽灯还是其他灯那是具体的实现。而当今世界最赚钱的是接口了。搞硬件都知道，很多硬件公司都是买接口的。接口是什么，就是一个解决问题的方案，一种抽象的思路。比如说，软件是什么，可以给一个规范的定义，然后，某东西是不是软件就是要拿这个规范去衡量。
当我想到这里的时候，第一次觉得敲代码跟现实的生活，更其他的事情有很多是相同的。这是设计模式让我学会思考的地方。
已知世界的近200种软件模式
四人帮把这些又抽象了一次。
先找到一些标准项目看看其模式应用
再考虑四人帮的模式吧
一年以前写的,当时也是第一次比较全面的了解设计模式。最近又有点想看看设计模式了，虽然没做过什么大项目，但随着时间积累，在这方面还是有些感触的。
设计模式其实可以适合很多人读的，搞it，当老板，搞销售的看都是不错的书。其实我更喜欢headfirst的设计模式，把复杂的事情描述的很简单，而且没有太多的关于理论的缀述。而四人帮的虽然也看了点，但针对"国情"，针对我们多数的实用主意者而言有点过于复杂。好比要求每个人都懂相对论一样，其实我们只要能在生活中活学活用一些物理常识不是更好。不过如果真的爱这口，想提高内功，经典的书还是要看的。 4 楼 抛出异常的爱 2010-04-26 orcl_zhang 写道抛出异常的爱 写道引用
花了一周多一点的时间看完了headfirst的设计模式。看完之后有一种恍然大悟的感觉，仔细想想有觉得自己好像什么也看懂。
简单说下对这本书的一点感悟吧，headfirst的书比较通俗易懂，之前看了四人帮的设计模式，看一半就有一种痛不欲生的感觉，自己水平有限，看不懂，也就没在勉强自己了。
对于模式其实简单来说，就是一种解决通用问题的通用方法。有哪些问题要解决呢。
软件工程中，最大的问题也就是在需求的变更，需要不断的更新版本。很多模式就是用来解决这个问题的，如何设计，才能更好的提高代码的可扩展性。比如说迭代器，状态模式，适配器模式等等。
另外的问题，在于如何让代码思路更清晰，更好的封装代码，比如说门面模式。
第三个问题就是在于对问题的理解方式，这点解释起来比较困难。比如说，多次提到的针对接口编程而非针对实现编程，将不变的变化得分开封装。其实这是回到一个很原始的问题，好比在说就是一座山，小和尚看到得就是山，老和尚看到就不一样了。设计模式教会我这样去思考代码，要针对接口编程，而非实现。就是说，如果我们晚上要看书？我们该如何解决，好找到能发光的东西。对了，这就是接口，至于你是用台灯还是白炽灯还是其他灯那是具体的实现。而当今世界最赚钱的是接口了。搞硬件都知道，很多硬件公司都是买接口的。接口是什么，就是一个解决问题的方案，一种抽象的思路。比如说，软件是什么，可以给一个规范的定义，然后，某东西是不是软件就是要拿这个规范去衡量。
当我想到这里的时候，第一次觉得敲代码跟现实的生活，更其他的事情有很多是相同的。这是设计模式让我学会思考的地方。
已知世界的近200种软件模式
四人帮把这些又抽象了一次。
先找到一些标准项目看看其模式应用
再考虑四人帮的模式吧
一年以前写的,当时也是第一次比较全面的了解设计模式。最近又有点想看看设计模式了，虽然没做过什么大项目，但随着时间积累，在这方面还是有些感触的。
设计模式其实可以适合很多人读的，搞it，当老板，搞销售的看都是不错的书。其实我更喜欢headfirst的设计模式，把复杂的事情描述的很简单，而且没有太多的关于理论的缀述。而四人帮的虽然也看了点，但针对"国情"，针对我们多数的实用主意者而言有点过于复杂。好比要求每个人都懂相对论一样，其实我们只要能在生活中活学活用一些物理常识不是更好。不过如果真的爱这口，想提高内功，经典的书还是要看的。
事实上在项目中用的模式都是那200多种。
只是抽象成23种了
如果你把数据库也当成模式的一部分
你会看到很多很多很多。。。。四不像的模式（23种以外的模式）
例如：我就不信你的项目中没有
树
审批
页面添写多个表格
打印模块
批量更新
使用其它包的API
ENUM结构
静态常量
定时任务
这些需求描述 5 楼 orcl_zhang 2010-04-26 抛出异常的爱 写道
事实上在项目中用的模式都是那200多种。
只是抽象成23种了
如果你把数据库也当成模式的一部分
你会看到很多很多很多。。。。四不像的模式（23种以外的模式）
例如：我就不信你的项目中没有
树
审批
页面添写多个表格
打印模块
批量更新
使用其它包的API
ENUM结构
静态常量
定时任务
这些需求描述
这些是经常用到。
只是在没有全面了解设计模式之前，没有体会到自己在用。
