|
锁定老帖子 主题：设计模式，今天你用了吗？
精华帖 (0) :: 良好帖 (8) :: 新手帖 (0) :: 隐藏帖 (14)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-05-14
说实话啊 你要只是一个大公司里的 初级看法人员 估计用不到什么模式
|
| 返回顶楼 | |
|
发表时间：2010-05-14
是呀，整天都在写增删改代码。。。。设计模式，只是自己扩充知识时的玩物
|
| 返回顶楼 | |
|
发表时间：2010-05-14
什么情况下用模式的？ 我用得最多的就只有 单例 和工厂了 别的 实在不知道在什么场景下用 谁给讲讲
|
| 返回顶楼 | |
|
发表时间：2010-05-15
我觉得，只要能经常回过头去看看前面完成的代码，然后将里面的坏味道给踢掉，就可以了，模式我觉得是一个比较教条的东西，理解就可以了，
|
| 返回顶楼 | |
|
发表时间：2010-05-15
mococa 写道 linux1689 写道 对于中初级读者而言，个人比较推荐《设计模式之禅》，出版后在社区里反响比较强烈，大家的评价都不错，在网店和实体书店的销量也不错，具体地可以看这里：http://book.douban.com/subject/4260618/。
这本书算是在研究了原来所有设计模式类图书的优劣后写作而成的，力图使设计模式变得易懂、易学，从读者朋友的反馈来看，目的基本上达到了。当然，这本书还远非完美，肯定还存在不少问题，我们会不断收集读者反馈，然后进一步完善。 也许这个帖子会遭到一些朋友的炮轰，因为有广告的嫌疑。说句实话，是有广告的目的，但是更重要的目的是希望真正给需要的人推荐一本比较好的关于设计模式的书。 欢迎大家讨论这本书，但是不喜欢看到没有根据的指责和谩骂，一则是对自己的言行不负责任，哦二则是不尊重作者的劳动成果，三则是指责和谩骂也不能给读者建设性意见。 看见书名带“禅”的就有股装#B的味 |
| 返回顶楼 | |
|
发表时间：2010-05-15
1、什么时候使用设计模式呢？
首先不应该考虑这个问题，应该考虑的是如何DRY。举个例子，比如在你绞尽脑汁为抽出两块逻辑结构完全相同，但中间的处理过程不同的代码发愁时，你自然就会去寻找一种把结构抽离出来的方法，最后也许你够聪明，自己发现了这种方法。也许你不够聪明，从网上、朋友那、同事那或者书上知道了有个叫模板模式的方法。 2、怎么防止过度设计？ 自顶向下的TDD吧，你所写出来的代码完全是由需求驱动出来的，没有测试（需求）不写代码，所以根本不会有多余的代码。 3、4，参考1。 5、DRY生万物。 6、重构值得一读，领悟这两篇帖子中gigix的话我觉得就差不多了（请无视seen）：http://www.iteye.com/topic/294651 http://www.iteye.com/topic/460125 |
| 返回顶楼 | |
|
发表时间：2010-05-15
bughammer 写道 1、什么时候使用设计模式呢？
首先不应该考虑这个问题，应该考虑的是如何DRY。举个例子，比如在你绞尽脑汁为抽出两块逻辑结构完全相同，但中间的处理过程不同的代码发愁时，你自然就会去寻找一种把结构抽离出来的方法，最后也许你够聪明，自己发现了这种方法。也许你不够聪明，从网上、朋友那、同事那或者书上知道了有个叫模板模式的方法。 这个就是我说的 推导出的设计模式 或者你用了设计模式但是不知道 后来才恍然大悟 这是模版模式 bughammer 写道 2、怎么防止过度设计？
自顶向下的TDD吧，你所写出来的代码完全是由需求驱动出来的，没有测试（需求）不写代码，所以根本不会有多余的代码。 过度设计这个问题 不是TDD就完全能解决的，同样一个问题，可以有很多设计方案，就是一个helloworld，你可以写出采用复杂的代码，有人还说可以用spring把bean配置进去呢 这个没有必要，但还是TDD设计的接口啊 敏捷中倡导的“简单”即满足当前需求，做出能工作的软件，在不断重构中可能方案会越来越复杂你可以使用模式、原则，得到好的设计 |
| 返回顶楼 | |
|
发表时间：2010-05-15
最后修改：2010-05-15
如果看TDD那本薄册子，应该知道，测试失败后要做的事仅仅是写出让测试程序通过的“最小改动”。你也说了“敏捷中倡导的“简单”即满足当前需求，做出能工作的软件“。
我就比较好奇一个期望程序输出一句helloworld的测试代码如何驱动出一套spring实现的helloworld。 |
| 返回顶楼 | |
|
发表时间：2010-05-15
最后修改：2010-05-15
首先，TDD 是测试驱动开发，其中包含了测试驱动设计的思想，也是一个过程和指导思想。测试驱动开发可以得到清晰的和尽可能少的依赖，可以得到松耦合，也可以得到简单的设计和代码。
完全避免过度设计不是TDD一个人的责任，他是敏捷的组成部分，TDD也不是孤立的，按照敏捷的原则、思想、过程，和其他实践（比如重构）、原则结合起来，这个过程来防止过度设计。 如何可以防止过度设计，大家可以另篇讨论。 纸上得来终觉浅，一切靠实践说话吧。 |
| 返回顶楼 | |
|
发表时间：2010-05-15
最后修改：2010-05-29
我只是想说，请不要用你所理解的TDD的概念误导他人。嗯，实践了再说话吧。（包括楼下那位）
|
| 返回顶楼 | |
