MicroHelper.Net

是的，模式要实事求是，应该是解决问题为主
我搜集了原则方面的文章，有空去看看吧
http://www.objecttutor.com/search.php?key=原则

楼主看来，功力不浅，哈哈
希望能到【面向对象辅导员】交流

“以行为为中心”，一切应该围绕接口来设计。
“我的原则是面向需求，面向问题．设计开发首先是解决需求和问题的．
其实模式问题只要继承．接口这些真正弄明白了，设计时自然就有自己合适的模式． ”

我是小朋友,都被你们说晕了.大家说话说明白点

最终你们还是要面向显示器！

我的原则是面向需求，面向问题．设计开发首先是解决需求和问题的．
其实模式问题只要继承．接口这些真正弄明白了，设计时自然就有自己合适的模式．

软件设计最重要的是降低系统的复杂性。目标是在满足当前需求的情况下选择最简单的方案，并适度考虑到将来复杂性的发展。原则太多了，其实相互之间会出现冲突。

非常同意Rover的说法，我在写程序的过程中发现很多人写程序往往为了模式而模式，舍本逐末。

谈谈我的想法：面向对象编程(OOP)首先考虑的应该是对象，分析设计时也考虑的是对象，根据对象来设计类，而是否要继承要看类有没有共性。对于面向对象的法则来说（单一职责，开放封闭等），它只是一种手段，设计时首先应该考虑的是对象，进而设计类，如果有共性的地方，是否继承一个基类更好（好，加），至于接口，我的理解是对象通过接口向对象发送消息。我的对象是否是稳定的（如果是稳定的，可能我不需要继承接口，直接new一个），设计模式强调针对接口编程，我认为也是一种手段，设计的时候我首先想到的是对象而不是接口，当然定义了接口也就是一种契约，继承的类必须实现，而事实是接口很难设计，有时候总要回过头重新设计接口。设计模式解决了类（对象）的结构问题，解耦等等，它只是一种手段。当我的对象以后可能更换时，就引入一个接口（针对接口编程），可能要使用工厂模式和其他相关模式...我认为设计时首先考虑需求，进而考虑对象，设计类，为了结构、扩展和灵活性使用设计模式，如果一上来就考虑接口和设计模式就造成了为了模式而模式。 我的流程是:需求->用例->对象（域模型，设计类）－->顺序图->边界对象(设计类)=>控制对象（设计类）－>改造结构（使用设计模式），考虑面对对象原则。

语言支持按合同设计也是一个方向。

兄台最近很少在博客堂现身呀：）

我们所做的一切都是为了一个目标，使软件开发更简单。编写简单，维护简单，修改简单。

围绕着这个目标，我们在不断的实践，实现这个目标，有几个方向，减少耦合，面向抽象，动态生成，数据驱动等等

从面向过程演化到面向对象，虽然最低层的机制是类似的，都是找到地址调用代码段，但是怎么样找到真正需要执行的代码段这是机器要做的事情，程序员可以在抽象的层面考虑问题，可以自顶向下的进行开发，可以在更广的范围考虑代码重用，表达抽象可以用继承、接口或者其他的手段，怎么样更好的利用抽象这一工具也总结出很多设计模式，随着人们的实践，工具的发展，一些新的模式出来，一些旧的模式消亡，接口的用处越来越广泛，传统的面向对象思想在发展，要泛型，要AOP，代码动态生成等等，配置文件越来越复杂，成为与源代码的一部分。

另外，在建模的方面，从代码生成以及双向工程，到集成现成模式到模型中，现在有的工具厂家尝试不用写代码就可以检查建模的正确性，还有的人在推可执行的uml。

总之，让机器越来越聪明，让人做的事情越来越简单。

Quoted from ASD-PPP:

Indeed, it is this inversion of dependencies that is the hallmark of good object-oriented design. It doesn't matter what language a program is written in. If its dependencies are inverted, it has an OO design. If its dependencies are not inverted, it has a procedural design.

也就是说，是否满足DIP原则是区分传统面向过程的设计和正经面向对象设计的关键所在——这是很多所谓面向对象设计者的重要误区，好像用了C++/Java/C#就面向对象了，其实根本就不是这样的。

当然，并不是说其他原则就不重要了，SRP/OCP/LSP等等其实都是用于验证一个设计是否从面向对象设计技术得到实际好处的基本原则。毕竟我们不是为了面向对象而面向对象，我们根本还是要通过利用面向对象技术在软件设计、开发与维护方面实实在在的得到好处，对吧！:)

@JGTM'2004 [MVP]

俺最强调的是开放封闭原则，不管开发人员用什么方法，只要能做到对扩展开放，对修改封闭，不是什么方法，都是好方法 ：）

当然OCP可能没有DIP那么好的直接指导实践。

OO的设计原则（包括面向接口的编程等等）大多可以从DIP推导出来——虽然不是所有的场合都需要应用DIP，然而我一直很强调DIP对于OOA/D的重要意义。夸张点儿说，DIP就是OO思想的一切，看一个人懂不懂OO，只要看他会不会灵活应用DIP就差不多了。:)

what on earth are you talk about?
are you talking to the book,<Agile Software Development Principles,Patterns,and Practices>,it is very diffrent what i have read.

一次讲不了那么多

...illuminating