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

woodheadz

其实只要你的代码是符合面向对象的基本原则的，你的代码里面就几乎必然会带有一个或几个模式。

实际使用的过程里面，多数时候都不是在“应用模式”，而是自然而然地发现你代码里面的设计模式，然后重构代码，使设计模式显性化，让代码更加易读和优雅。   

对设计模式的理解，其实关键还是对面向对象的理解。 这个急不得的，你只能从小处入手，重视自己的代码质量，思考自己的代码是否符合面向对象设计几大原则 ，并且养成重构的习惯。慢慢的，你就发现设计模式自然而然就会出现在你的代码里面了。

当然不懂这些一样可以coding，只是会做得比较累。非面向对象的代码一般相对而言代码质量差，BUG多，修改比较困难。越复杂的程序，这种差别就越明显。

现在我们公司的活，不懂设计模式基本上是没法入手的。

[ 本帖最后由 woodheadz 于 26-4-2010 22:14 编辑 ]

woodheadz

原帖由 valpa 于 26-4-2010 22:39 发表

                               
登录/注册后可看大图

十分不同意，俺最喜欢C，最喜欢的是Linux Kernel，不否认里面用了OO的一些思想
但是这位同学说非OO的语言不能设计复杂的软件，俺是非常不同意的
OO语言写得烂的Bug也超多，关键在于写代码的人的水平，而不在于语言 ...

楼上理解错我的意思了。 关键不在于OO的语言，而在于OO的思想。 有好的OO思想，甚至用C语言也能写出很不错的带有OO风格的代码来。
“非OO的语言不能设计复杂的软件”这话是你自己说的，和我可没有什么关系。
不过嘛，呵呵，C语言毕竟是太老了些。除非是嵌入式或者基于老系统的开发，不然普通的新系统还在用C开发的确实很少听说。
C语言比新的OO语言的劣势，尤其是生产率的劣势我想不用我说了。

woodheadz

原帖由 浮云 于 26-4-2010 22:52 发表

                               
登录/注册后可看大图

woodheadz筒子说的比我到位呵呵。我好像说错了，是面对对象发展和smalltalk有关。这个和模式应该没什么直接关系。
另外他说的意思我觉得是说不符合OO思想的代码比较容易烂，但这不一定是说非OO的语言就是烂的。c是非 ...

呵呵，好像早期的很多面向对象思想都是来源于用smalltalk的人的哈... 只可惜我到现在都没见过smalltalk长什么样...

woodheadz

原帖由 key 于 28-4-2010 16:48 发表

                               
登录/注册后可看大图

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

其实我觉得，大可不必把这当成是一种无奈。 就把重构看作是我们每天的例行动作，就像敲击键盘一样，不也挺好吗？
铁匠用锤子来锻造铁器，我们用重构来锻造系统，这些都不过是我们使用的工具而已。
UML拿来做沟通交流的工具就好了，至于开发，模型驱动的方法，我始终认为是在学院派的理想环境下才能行的懂的特例。人性本身就是不完整的，所以在实践中所以怎么可能会有那么顺利的场景让你一步步模型驱动呢？

woodheadz

原帖由 key 于 29-4-2010 21:27 发表

                               
登录/注册后可看大图

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

从一开始就设计高大全的的系统当然没有必要，
所以才有agile，xp之类的方法。
我比较接受的一个观点是，提取其中具有典型意义 ...

把重构和死亡联系起来，我想你是过头了。 我本来还觉得我们对重构的观点都差不多，但现在看起来还是有很大的不同呢
有一个很好的例子，可以说明我们的区别。 就像我们都知道需求的变化不可避免，在这个事实面前，有两种几乎是背道而驰，而又特点鲜明的做法：
1.以CMM等方法为代表的"学院派"（姑且称为）强调对需求的绝对控制。通过流程进行审核，审慎地将需求引入到开发迭代中。
2.以XP为代表的“敏捷派”则强调拥抱变化，整个XP的基础都是建立在“变化”这一个关键字上的，需求的变化将直接推动系统的进化。化被动为主动。

你所理解的refactor，其实是在被逼无奈的情况下，被动的对代码进行修改。也许你也用了重构工具，使用了经典的重构方法，并且还编写的unit test保证重构的结果，但这些都是在没有其它的办法的情况下进行的“亡羊补牢”的措施而已。就像前面例子里的“学院派”，虽然认识到修改不可避免，但还是尽全力避免修改，力图让修改最小化。你对系统的设计，绝大多数（最少你希望是绝大多数）是在前期的设计就通过UML完成了的。
我所理解的refactor，就像编写程序必须要敲入代码，编译一样，是再理所当然不过的编程的必然步骤，而且重构还是编程步骤中我最喜欢的一个（以前是编译， ）. 我每天coding的过程其实就是不断的编码，编译，测试，重构再测试。我对系统的设计，是在我的整个coding过程中完成，重构是我两个最重要的设计步骤之一。另一个嘛，其实就是编码了  “代码即设计！”，呵呵。 相对你而言，我就比较”敏捷派“了。  我也经常用UML，但多数时候是和同事讨论时候用的，多数是画在白板上和纸上。 事实上，我目前的工作电脑上连画UML的工具都没有，只有家里的电脑有个UModel。 当然这个也和我的工作性质有关（我们是做产品的公司，不用和客户进行技术交流）。

其实我不想比较那种方法（或者说那种“派”，呵呵）更好，每种都有自己的长处。我自己做过一段时间的外包，在多数的外包的环境下，确实“敏捷”是完全行不通的。但我始终觉得，敏捷方法的效率，系统的质量，成本都有非常明显的优势。只是敏捷对团队中个人的要求要偏高，而重型方法则有可能用管理方法组织起大量的人力来完成项目吧。

[ 本帖最后由 woodheadz 于 29-4-2010 23:58 编辑 ]

woodheadz

呵呵，我喜欢这样的讨论，我想我们两个都会从中有所收益

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

1.这个问题，恰好就是很多人质疑敏捷方法的地方。 我的回答是：面对面的交流 + 结对编程（我几乎和每个团队成员都结对过） + Code review + 部分UML
我刚好在一个大型产品项目的一个子系统开发团队内担任过architect,我觉得在我们当时的环境下（因为要参加一个国外的行业展览，所以工期紧，而产品部门过来的需求变化很快），这种做法最后的效果还可以接受。 我后来跳槽到一家以外包为主要方向的公司，那边就是以文档为主要交流手段的。 我没有办法想象如果我在前家公司的项目中依赖文档作为主要交流手段会是什么样的一个结果。
当然这种方法不可能用于很大的团队，但是如果团队很大，而不划分成一个个的小团队以至于不能用这种方法，是不是也说明这个团队的组织有问题？

2.第三方组件的问题，我们在项目的前期或者中期都曾经做过引入第三方组件的决策。 我觉得这个是一个风险控制的问题，如果我觉得某个地方不采用第三方组件可能有风险，我自然会把这个模块放到最优先开发的列表中，尽早确定是否采用第三方组件。

3.我用的UML大多数是类图和时序图，我画UML的主要目的就是为了交流。我很不喜欢包含很多细节的UML，我觉得与其看这样的UML，还不如去看代码更清楚。
我最近比较喜欢这个：
http://yuml.me/

                               
登录/注册后可看大图

4.我不做reverse engineering，理由见第三点

[ 本帖最后由 woodheadz 于 30-4-2010 12:08 编辑 ]