实际写代码 interface, design pattern用的多么？

key

重构是无可避免的，但模式是否只能在重构时体现，我觉得就未必了。
我试过由基础uml做起，一步步地形成架构、类图，在架构和类图阶段引入模式，比较顺理成章。
但事实上我们在写系统时，又基本上无可避免地先代码，然后code review，然后refactor。
这算是一种无奈吧。

原帖由 Yok 于 26-4-2010 14:32 发表

                               
登录/注册后可看大图

接口，模式应该指上无，心中有，在重构时在成型也不迟
如果你是用Windsor做DI的话，不用接口，方法声明为virtual也是可以的

key

我不认同你的观点。正如我在上面所说的，refactor是无可避免；但如果design pattern只能应用于refactoring，那也只是一种无奈。

过去一段时间，我构建了若干个重要的程序框架，虽然说不上漂亮，但由设计开始应用好的方法和架构，的确能带来不少好处。
比如有一个网络协议解释框架，当时我想到的只是两三个协议的应用。我拿出其中一个协议，从use cases做起：

use cases -> sequence diagram -> system architecture -> class diagram -> coding -> testing

其中在sequence diagram与system architecture中间开始考虑design pattern的引入，再在class diagram的时间把design pattern精化，
最后形成第一套代码。这样形成的代码在之后的几个月被扩展到两三万行，一直都比较顺利。

原帖由 woodheadz 于 28-4-2010 19:59 发表

                               
登录/注册后可看大图

其实我觉得，大可不必把这当成是一种无奈。 就把重构看作是我们每天的例行动作，就像敲击键盘一样，不也挺好吗？
铁匠用锤子来锻造铁器，我们用重构来锻造系统，这些都不过是我们使用的工具而已。
UML拿来做沟 ...

key

很同意你在这里提到unit test这个考虑因素。
其实很多实现上的考虑，如果没有unit test这一环，考虑点会有很大的不同。
我因为要建立testcase而refactor了好多次代码后，终于明白到这个道理。

原帖由 lol 于 29-4-2010 15:09 发表

                               
登录/注册后可看大图

那个例子没有很复杂啊，其实没有加多少代码，好处就是每个文件都小，每个类都只要关注一样东西。实际开发一定都会用到类似的东西： http://www.objectmentor.com/reso ... es_and_Patterns.pdf

...

key

无可避免不等于完全依赖，
就象人是无可避免地要死的，但自杀就没有必要了，对吧？

从一开始就设计高大全的的系统当然没有必要，
所以才有agile，xp之类的方法。
我比较接受的一个观点是，提取其中具有典型意义的若干个use cases进行设计和实现，
不断回归扩展，最后建立整套系统。

原帖由 ironcool 于 29-4-2010 17:16 发表

                               
登录/注册后可看大图

我觉得重构是无法避免的。
我认为绝大多数项目或系统，在真正深入进行代码编写工作前，设计者都无法考虑到所有的问题。如果能够预先画个很漂亮的圈子并
遵照此路线百分百完美实现，基本上说明这个系统还是比较简单 ...

key

我对重构的理解并不局限于你所说的范围，这个就先不谈了。我们不妨基于你所说的一些内容做一些讨论。

我对系统的设计，是在我的整个coding过程中完成，重构是我两个最重要的设计步骤之一。

我想知道，

1. 如果你做一个tech leader或Architect，如何让你的同事了解他们要做什么？怎样用好你的设计？
2. 你如何知道哪些第三方组件需要引入，什么时候引入，为什么要引入？

我也经常用UML，但多数时候是和同事讨论时候用的，多数是画在白板上和纸上。 事实上，我目前的工作电脑上连画UML的工具都没有，只有家里的电脑有个UModel。 当然这个也和我的工作性质有关（我们是做产品的公司，不用和客户进行技术交流）。

我想知道：
1. 你用uml画了哪些图？为什么要画这些图？
2. 你做reverse engineering吗？

原帖由 woodheadz 于 29-4-2010 23:21 发表

                               
登录/注册后可看大图

把重构和死亡联系起来，我想你是过头了。 我本来还觉得我们对重构的观点都差不多，但现在看起来还是有很大的不同呢
有一个很好的例子，可以说明我们的区别。 就像我们都知道需求的变化不可避免，在这个 ...