请教一下设计方面的问题？
上个星期自己看了一下设计模式，真是受益匪浅呀，觉得面向对象的设计最大的好处并不是什么“可复用”性（可能自己还没到那个层次），感觉它的最大好处还是软件设计脉络清晰，随之而来的自然是好维护喽，还有就是扩展性也会有很好的体现。。。自己尝试着写了一个简单的demo，需求也很简单，就是分析一下数据，每条数据都有对应的状态，然后不同状态的业务规则基本都有一些不同。。。
因为考虑到这个功能的主要变化对象是状态，所以我将所有状态提取出来，写成相应的类，然后“套用”简单工厂设计模式（其实方法工厂也差不多，因为只是一个demo，所以以方便为主），感觉设计开始还是蛮轻松的，可是随着业务融入代码感觉越来越复杂了。。。
这儿想请教一下，都说设计与表现无关，但是到具体开发中还是有一些困惑的，例如：在上面的例子中有一宗状态需要通过查询数据库来判断，那么这块代码该写在哪儿好呢？如果直接写在某一状态类里面，那么这份代码的可复用性根本就没有了吧？
可能没怎么描述清楚，希望大牛们帮帮忙，不懂请留言！
好了，该上班去了！
加油！ --------------------编程问答-------------------- 明明不需要多数据库
偏偏要套上设计模式
然后硬把数据库分为sqlserver mysql Oralce sqlite txt --------------------编程问答-------------------- 设计模式是典型给“操作工”的一份说明书。它本身不是设计，而是实现设计的模式。它不会为什么可复用性、扩展性或者维护性背书。 --------------------编程问答--------------------
其实也不是，只是看看别人是怎么抽象业务的，不得不说是智慧的结晶。。。
当你刚开始感觉到别人把业务顺理得那么“合理”不震撼么？ --------------------编程问答-------------------- 设计模式是为各种需求服务的，确切说的仅仅是提供了一种解决方案而已。
如果在设计中硬要把设计模式往里面套，那就是一种本末倒置的行为/ --------------------编程问答--------------------
是有人读死书罢了，当然不排除别人好奇。
不能举一反三灵活运用能有什么进步呢？
这些都是套路，实践还是要靠自己，当你看OO看到反感，难道不想看看别人怎么玩OO的吗？
设计模式就是遵守了OO很多原则而设计的套路或者说案例！ --------------------编程问答-------------------- 解二元一次方程组有很多种办法，正常的思路应该是先看题目的具体内容，再选择一种适合的方法。
而不是你所想的，你学会了一种解法，然后要根据这种解法去找适合的题目，或者你碰到任何题目都千方百计的往这种解法上面靠，这已经搞反了。 --------------------编程问答--------------------
我怕了！
为什么就一定认为我硬是在套设计模式呢？？
难道我我分析的一点价值都没有么？？
首先你得遵守一些规则吧？至少你得想想以后怎么好维护扩展吧？
至少也看看题目，再说说我错在哪儿吧？ --------------------编程问答--------------------
就是是硬套设计模式，那至少我也得考虑一下该套什么模式呀！
--------------------编程问答-------------------- 是哦,就算带套,也得先学习怎么带,带什么套
--------------------编程问答--------------------
因为考虑到这个功能的主要变化对象是状态，所以我将所有状态提取出来，写成相应的类，然后“套用”简单工厂设计模式（其实方法工厂也差不多，因为只是一个demo，所以以方便为主），感觉设计开始还是蛮轻松的，可是随着业务融入代码感觉越来越复杂了。。。为什么会随着业务融入代码感觉越来越复杂
那是因为在一开始你就没有好好的分析业务，抱着使用设计模式的想法去做的开头，脑袋里想的是，自己已经掌握了23种高尖端武器，没有什么攻不破的城墙。然后在没有把业务分析明白的情况下就开始一点点的把你的高尖端武器塞到了项目里。当你把坦克和直升飞机组合都一起后才发现这两者都没法跨过太平洋，然后就想在太平洋上修一座大桥，好让你的高尖端武器能顺利通过，修着修着你终于感觉力不从心，越来越难，越来越难，然后你就发了这个帖子。
软件开发是正向工程，是从需求到设计，再到开始测试的过程。软件工程不存在银弹，设计模式顶多算是一颗小小的子弹，当你发现一个目标，而你手头的猎枪正好需要设计模式这颗子弹的时候你把设计模式打出去，那么这就是成功的设计。更简单的来说，你只需要知道那些设计模式可以解决什么问题，将来当你碰到类似的问题去看一看是否可以套用已有的设计模式，对于设计模式的学习，达到这种程序就可以了。
当然你可以说架构师肯定不止于此，确实是这样的，架构师可不仅仅是这种程度。不过架构师也是从需求开始，分析业务，然后提出解决方案。那种靠着自己脑袋中虚构的业务需求想出一种解决方案，然后让业务开发人员千方百计往架构里塞业务代码的架构师就是正宗的伪架构师。 --------------------编程问答-------------------- --------------------编程问答--------------------
“那种靠着自己脑袋中虚构的业务需求想出一种解决方案，然后让业务开发人员千方百计往架构里塞业务代码的架构师就是正宗的伪架构师。”这句不是很好吧。。。
架构师也需要对业务领域的了解呀，了解越多，走的歪路就越少，以后需要修改的也就越少了，当一名架构师需要设计到自己不擅长的领域的时候，当然只能根据自己的判断啦，根据自己以往的经验来推测。。。
如果当一名程序员达到架构师的地步，“那种靠着自己脑袋中虚构的业务需求想出一种解决方案”这种完全靠想象应该是不存在的吧？ --------------------编程问答--------------------
换句话说，我们应该遵循的是设计原则，而不是什么设计模式（设计模式本来也是遵循设计原则的），也就是说，我们只能根据对当前业务的理解，按照设计原则去写代码，这么有什么不对吗？ --------------------编程问答--------------------
上面只是一个demo，我可以尝试着加一些业务进去（当然，可能是位了某种模式而添加的业务），其实这里并不矛盾，我只是想了解那些“业务功能”需要接触到“数据处理”时，我该怎么写这些代码？？？
是直接写在相应的类里面，还是有什么方法隔离出来？？？
我只是想问问，因为有些答案真的很震撼！！！
--------------------编程问答-------------------- --------------------编程问答-------------------- 一个C程序员应该为现在主流编程语言不再需要大部分“设计模式”就能用语言内置的特性完成设计意图而到震撼。什么叫设计模式，从更抽象的语言的角度看，无非就是人肉编译器展开。 --------------------编程问答-------------------- 最典型的例子就包括lz说的“工厂模式”，现在支持RTTI/RTTC（对于C#来说，叫做“反射”，对于动态语言来说，根本连反射这个名字都无所谓了）的语言都不再需要工厂模式。还有委托之余策略模式、模板模式等等。 --------------------编程问答-------------------- 之余-〉之于。
再比如，“装饰模式”也被C# 3.0的扩展方法从语言层面解决了。“代理模式/适配器模式”被表达式树乃至语法树解决了，“观察者模式”被事件解决了——事实上反射+接口+泛型+委托这4个特性的组合能够把大部分GoF设计模式（C/C++很多模式都是在对这4个C/C++中缺乏语言级支持的特性的模拟）精炼成几行代码，以至于探讨什么模式已经不重要了。 --------------------编程问答--------------------
是的，讨论设么模式是不那么重要。。。
重要的是“设计原则”，重要的是OO的特性，重要的是别人如何来抽象！！！
只有反反复复的“纠结”才能进步！ --------------------编程问答-------------------- 设计原则不是设计模式背书的。这我前面早就讲了。
这就好比菜刀并不为它是凶器还是厨具背书，混凝土也不为房屋的结构背书一样。设计模式和设计没有一点关系。 --------------------编程问答-------------------- 至于“设计原则”，更是一个极其扯淡的东西。
如果简单的几条设计原则就是设计的全部的话，那么架构师真的可以回家抱孙子了。 --------------------编程问答--------------------
呵呵，谁说了是全部了，我只是说尽量遵守那些贵重罢了。。。
还有，我是来请教的，可能你已经到我完全理解不了的高度，我只有仰望！！
--------------------编程问答-------------------- 我是来寻求帮助的。。。
一个好老师的评判标准不是他多么有学问，而是他可以传授到少东西给别人。
当然我没这个权利要求大家。。
只能感谢愿意帮助我的人！！！
谢谢！ --------------------编程问答-------------------- 我是来寻求帮助的。。。
一个好老师的评判标准不是他多么有学问，而是他可以传授到少东西给别人。
当然我没这个权利要求大家。。
只能感谢愿意帮助我的人！！！
谢谢！ --------------------编程问答-------------------- 你想要设计的原则，那就告诉你两天最基本的，高内聚，低耦合。
--------------------编程问答-------------------- 论坛里,凡是谁发了一帖学习设计模式的帖子,必定遭到炮轰,炮轰的理由,大概有:
1. 设计模式不能学习,特别是不能看书学习
2. 设计模式不能靠背书
3. 设计模式不能硬套
4. 上面三条有一条成立,架构师回家抱孙子
--------------------编程问答-------------------- 按设计模式写自己的程序是一种好习惯
我觉得吧，设计模式这种东西是很好
但是也不要所有的都用设计模式
比如随便写一个小程序
几十行代码的事
就不需要设计其他模块了 --------------------编程问答--------------------
反了反了
越小的程序越要注重设计模式啊
像我等菜鸟
没能力把控大项目
只能从小作起
只能找些小项目来看书学习再硬套设计模式
--------------------编程问答--------------------
没有一个架构师是“尽量遵守那些规则”的。不是说蹩脚的架构师遵守的规则少一些，而优秀的架构师遵守的规则多一些。如果你这么认为，你的方向都大错特错了。优秀的架构师优秀在于，它可以以更低的成本更精确地实现客户的需求，请注意更低的成本和更精确地实现这两个词，它是一种折中、妥协、权变和平衡的艺术。
我举一个经典的例子，比如对于如何用C++去封装Windows的消息，微软的架构师使用了消息映射宏，我想很多学了C++几天的人都会想当然地使用继承和虚函数，而他们得到的“规则”是，宏是不好的东西，纯粹的OO设计才是最好的，这样的分歧就是我说的真正的架构师和蹩脚的架构师的分歧，前者懂得权变、妥协，他们敢于使用反模式（违背模式和原则），尤其是在大规模的生产代码中这么做（MFC的这一设计延续了20年，经得起考验）。 --------------------编程问答--------------------
谢谢，这个听了比较直白！！
很好。。。
就是被炮轰可是一种过程吧！
没事！ --------------------编程问答--------------------
我说的是比较基本的，比如说什么“单一职责、面向接口编程……”这些不是最基本的么？
哎，这就是差距！！！
--------------------编程问答--------------------
我觉得这样很好啊，如果小的程序你都不知道该怎么考虑，功能比较多的程序就更容易没头绪了。。。
先易后难，学习过程而已！！
当然尝试着看一些比较复杂的项目也好，但前提是有这样的机会，我说的尽量是在工作中…… --------------------编程问答--------------------
虽然MFC很古老了
虽然MFC落后VCL几条街
虽然MFC的设计有很多蹩脚的地方
虽然宏确实是不好的东西
但是
你就不能举个浅显点,大家都能反驳的例子啊
一上来就拿微软架构师和初学C++几天的人作比较
明显有违你所说的:折中、妥协、权变和平衡的艺术啊
--------------------编程问答--------------------
呵呵，哥们谢谢你为我说话，我确实需要浅显一点的例子。
但是，但是，小弟是用c#写的！
哈哈哈~~~ --------------------编程问答--------------------
同意以上观点。。。 --------------------编程问答-------------------- 我觉得这玩意有点像学自行车,有点靠天赋.有些事,说不清,只能靠自己悟. --------------------编程问答-------------------- 先当个几年的码奴再来考虑设计模式这些事吧.这些事对于初学者,言之尚早. --------------------编程问答-------------------- 设计模式类似九九乘法口诀，你不会也可以按照加法做（重复无意义工作），会了也只是你可能会乘法的开始…… --------------------编程问答--------------------
整天码那些垃圾代码
再码几年也仍然是垃圾代码
还不如一开始就好好学习设计模式
就算不能运用自如
但碰到相关问题时可以背书硬套
成名要趁早
学习设计模式也要趁早
工作几年
人会变懒的
别说学习
翻书的心都没了
--------------------编程问答-------------------- 设计模式是前辈们总结出来的经验，遇到什么问题，用哪种方式会有更好的体验。
工作中因为遇到的问题不一样总是会根据不同的需求去精炼自己的代码。
当一份代码进行反复的重构后发现 已经可以满足需求了，那么你会发现这份代码和前辈们总结的设计模式及其相似。
当一个程序员本着设计模式的几大原则去设计代码而不是设计模式的时候，他设计出来的代码已经相似于设计模式了。
当一个老练的coding在看到需求的时候，充分考虑到了需求的变化，代码的重用，以后的拓展，维护，根据以前精炼过的代码模式重现使用，设计模式算是用好了。 --------------------编程问答-------------------- 没有码足够多的代码，就开始做设计工作是不合理的。码垃圾代码并不是件坏事，代码写完不是就抛弃的，架构师是在不断地重构中成长起来的，就像楼主认为自己写的代码不够好，这时就是重新抽象、重构代码的时候，每完成一次重构都是一次成长。 --------------------编程问答-------------------- 楼主只是问了个简单的问题，被你们这些自认为牛逼的人回答的不知所云了，简单的问题被你们搞得这么复杂，越看越晕，你们牛逼的答案和楼主的问题已经脱节了！ --------------------编程问答-------------------- caozhy 的境界太高了，就像独孤九剑和太极剑的最高境界都是重剑意，忘剑招，
但是要达到这样境界，除了高天资外，还需要使用剑招在不断的实战中体会剑意，我等小辈剑招还未能使全就想领悟剑意实乃好高骛远，我觉得还是踏踏实实把剑招练熟，多实战，剑意强求不得，到火候时自然领悟。 --------------------编程问答-------------------- 按照您对业务的要求，可以参考设计模式中的基本设计方法之一，即将不变的和变化的部分继续分离。可以将数据查询的部分设计为一个接口，如数据查询器接口，然后通过不同数据库类型的实现类实现这个接口。然后，就可以在业务模块中随时更换不同类型的数据库查询类，以达到灵活复用的目的。可以参考.NET架构中，IDataAdapter > DbDataAdapter > SqlDataAdapter,OledbDataAdapter的设计思路。 --------------------编程问答-------------------- 按照您对业务的要求，可以参考设计模式中的基本设计方法之一，即将不变的和变化的部分继续分离。可以将数据查询的部分设计为一个接口，如数据查询器接口，然后通过不同数据库类型的实现类实现这个接口。然后，就可以在业务模块中随时更换不同类型的数据库查询类，以达到灵活复用的目的。可以参考.NET架构中，IDataAdapter > DbDataAdapter > SqlDataAdapter,OledbDataAdapter的设计思路。 --------------------编程问答-------------------- 另外可关注一下状态模式。 --------------------编程问答-------------------- 设计模式涉及程序架构，服务器，通讯协议，操作系统平台，不是一天两天能搞懂的。
其实谁都想做到架构师，只编码是不能涉及到广泛的知识面的。
LZ为你推荐一个神级人物：
ROCKFORD LHOTKA是一位著有大量书籍的作者，其中包括那本Expeert VB 2005 Business Objects。他是微软的地区总监，微软最有价值专家和INETA的发言人。ROCKFORD在全世界无数的会议和用户组中发表演讲，并且他还是MSDN在线的一位专栏作者。除此之外，ROCKFORD是Magenic Technologies(WWW．magenic．corn)的首席技术官，MagenicTechnologies是微软在美国最重要的金牌授权合作伙伴之一，致力于使用百分之百来自微软的工具和技术来解决当前最具挑战性的业务问题。
--------------------编程问答-------------------- 冰冻三尺，非一日之寒
我要加油！！！ --------------------编程问答-------------------- 不得不说，caozhy的确是高人，用语言特性实现设计模式强于自己实现的说法，确实很有道理。 --------------------编程问答-------------------- 谢谢各位啦。。。
有段时间没来了，后面还是有很多朋友帮忙。。。
其实我只想参考一下大家的意见，我提的是一个具体的问题，我想知道大家怎么处理的，或者说有没有更好的处理方法？
你们那种处理方式有什么好处？ --------------------编程问答-------------------- --------------------编程问答--------------------
好帖，老曹的那个人肉编译器 让我想到了 企业级应用架构设计一书中的几个观点
分享之（需要你去理解而不是绝对的单方面看）：
若想设计出好的软件，普通的设计原则就够了。你并不特别需要模式，不过某个问题恰好由某个模式解决，那么该模式将成为解决问题的捷径。模式并不一定是某个问题的终极解决方案，使用模式也不会让你的代码更好，或者执行速度更快。
--------------------编程问答--------------------
呵呵，说的对呀！
有什么资料可以推荐下呗！
设计方面的菜鸟，以前差不多都是函数式编程，想到哪儿写哪儿，这样不但现在容易没有头绪（放下一会儿可能就忘记了，不知道该些什么了），而且以后也非常不好维护，早就违背了写最好的代码做相同的事这个准则。 --------------------编程问答--------------------
《Microsoft .Net 企业级应用架构设计》 推荐给你
--------------------编程问答--------------------
谢啦！！！ --------------------编程问答-------------------- --------------------编程问答-------------------- 谢啦！！！ --------------------编程问答-------------------- 谢啦！！！ --------------------编程问答-------------------- --------------------编程问答-------------------- 设计模式那本书比较好，大家推荐一下 --------------------编程问答-------------------- 大话设计模式 --------------------编程问答-------------------- 没有痛苦的经历是体验不到设计模式的好处的 --------------------编程问答-------------------- 大话设计模式 --------------------编程问答-------------------- 仰视。
然后脖子酸了。 --------------------编程问答-------------------- 不，也酸了，不知为什么 --------------------编程问答-------------------- --------------------编程问答-------------------- 对大师顶礼膜拜，期待大师出现 --------------------编程问答-------------------- cao版说的对，其实通用设计原则足够了，而设计模式其实是36计，通用设计原则则是孙子兵法和战争论
36计各说各有理，但怎么用则需参考原则。而真正的兵家实际更喜欢孙子兵法，因为有他你不仅可以36计，更可以自己玩37计，38计------
个人推荐“冒号课堂”这本书，不光讲设计原则，还会横向比较各种编程语言的思维方式。
接着在说你的疑问，你有疑问很正常。因为这是你一个人在做菜，洗菜，切菜，做菜，端盘子，洗碗都是以自己在做，所以你说我们为啥不可以这边锅里炖着肉，那边我还可以切菜。这样不是更加并行化吗？
我们说假设你把职责分开。不在是你一个搞，状态是吧，我不管状态时是存在数据库，还是存在文本xml。我不关心，反正有人会把这个状态弄出来（比比看，厨房的大师傅。青椒肉丝是吧，我下锅掌握味道火候就是了，至于谁洗的菜，谁切的菜，谁传的菜，和我没关系。反正有人洗，有人切，有人传，有人配，我只管做我自己该的事情就ok） --------------------编程问答-------------------- 各做各的事，你不要去关心这一层不关心的事情就是解决方法
其实看一下现实就ok了，你的老板关心的是怎么把公司发展壮大，而你关心的是怎么实现客户的要求，完成任务。这个职责不能乱。要是你的老板天天盯着你怎么敲代码，而你则天天在敲代码的时候则想着怎么把公司发展壮大，那这个公司你没的玩了。
同样站在设计的角度，我们就不会去考虑具体实现，你只要知道这个设计是能被实现的ok。至于具体实现，ok则是另外的问题。我可以再其他地方去完成，DTO，BO，VO各有各场景，而手段你cast转可以，你反射可以，你ORM也可以，你依赖注入可以，总之你心里明白这个设计可以被实现就好了，而具体实现延后在说 --------------------编程问答--------------------
这些讲得很好哇！
不过感觉还有有一点偏离我的意思了。。。
我就是一个“切菜”的，我是不用管别人怎么弄，但是我想知道的是这个菜怎么切才好，切出来的形状既适合用做某某的配菜，又可以做某某主菜！
呵呵！ --------------------编程问答--------------------
本来那个设计已经比较清晰了，但是随着代码的推进，总是发下里面某个类里面的方法在执行时需要判断一下，我想问的就是那个“判断”是不是也该抽提出来？？
或者有其他跟好的方法。。
具体的设计请看：设计方案，请教一下大家的意见。 --------------------编程问答-------------------- 《大话设计模式》封面，大鸟面前有三本书，最上面那本叫《重构》...
你在最开始的设计可能用简单工厂就能解决，但是随着需求的增加，你发现简单工厂已经不能胜任，这时你应该考虑的是重构...去根据设计原则重新组织更为合理的模式，以应对之后的需求。 --------------------编程问答-------------------- 再多说一句，其实简单工厂模式并不符合 开放-封闭原则...
为什么不符合，你想想就知道了... --------------------编程问答--------------------
再加上个反射呢? --------------------编程问答-------------------- 设计模式只是一个我们可以遵循的框架，
当应用到具体实例后，框架也就消失了 。 --------------------编程问答--------------------
光动动嘴都会觉得轻松，但是一旦编码、一旦让用户来挑剔，你才知道什么叫做困难。所以我们要少搞空洞的理论，而要将理论变得实用和直截了当。 --------------------编程问答-------------------- 这里不要一味地纠缠什么“是非黑白”。编程是一个设计过程，特别是当一个产品需要不断重构时，它是辩证的过程，整天满脑子“是非”的人来设计软件会越来越死、会把脑子疯掉。软件工程以测试为准，而不是以理论为准。 --------------------编程问答--------------------
是这样的呀，我正在实现呀！ --------------------编程问答--------------------
其实通过别人的代码可以更加了解语言，更加清晰的认识别人是怎么摆弄这些代码的，怎么在封装、继承、多态的，确实也是一个温故知新的过程，当自己对这些不能有更深的认知的时候，不妨借别人的思想来理解下，说不定会有意想不到的效果。 --------------------编程问答-------------------- 多应用一下模式 --------------------编程问答-------------------- 谢啦！！！ --------------------编程问答-------------------- 通用设计原则足够 --------------------编程问答-------------------- “手上有一把锤子，所以看什么都是钉子”，待你手上有多种工具的时候，就能够客观的看待问题了。
楼主可以看看《建筑的永恒之道》来体会模式与真正的设计的关系。
《设计模式解析》也说的很好，可以作为进阶读物。 --------------------编程问答-------------------- 激动啊，既然到“社区焦点”栏目去了。。。
哈哈哈~~~~ --------------------编程问答-------------------- --------------------编程问答-------------------- 大师兄，二师兄说的对啊！ --------------------编程问答-------------------- 设计模式什么的都是耍流氓
建议楼主看看 Clean code || Refactoring
看完之后在看设计模式什么的会有不一样的感觉！
--------------------编程问答--------------------
呵呵，谢谢啦！ --------------------编程问答--------------------
谢谢子夜推荐，不过看E文比较吃力呀！ --------------------编程问答-------------------- 初看设计模式应该防止过度设计。 --------------------编程问答--------------------
这个说得太好了。 --------------------编程问答-------------------- 大话设计模式 --------------------编程问答-------------------- 设计模式为我们提供了很好的思想。
但我觉得在使用别人的思想之前，要能清晰的知道如何提取对象，以及如何设定对象之间的关系，
这样才能发挥其效应吧。 --------------------编程问答-------------------- 看了这么久了，现在我感觉最困难的是面对功能需求，不知道该怎么将业务用代码表现出来。。。
有些设计模式因为业务比较好理解，所以对那些代码也比较好理解，比如说：“策略模式”。。。
这个是查哪方面的能力呢？？？ --------------------编程问答--------------------
是呀，这个就是比较困难的地方呀。。。
“设计模式”可以看成比较典型的“营销案例”吧。。。 --------------------编程问答-------------------- 看到UML图脑子里面也没有清晰的代码结构，
不知道大家怎么样？？？ --------------------编程问答-------------------- 实际上很多理解设计模式的人，对于模式的使用都是保守的，因为模式的使用是有代价的。千万不要学了设计模式之后就把它当做唯一的救命稻草。设计模式很大程度上是依赖于代码量（例如，10万行）和项目经验的积累的。如果项目规模本身非常小，盲目引入模式将会得不偿失。
你可以先尝试用最直接的方法，把业务逻辑分解成一个个可以具体实现的模块，也就是最传统的“自顶向下，逐步求精”的作法。别看这个做法原始，简单，但是非常管用。可以这么说，基本上所有的项目都离不开“分解-合成”的套路。等你分解的差不多了，在整合的时候通常会碰到可扩展性可维护性的问题。这个时候就可以根据需求的变化，考虑重构，看看是否可通过引入模式解决问题。
引入设计模式必须同时满足两个条件：
1. 你已经对于需求和业务逻辑有了非常清晰正确的理解。
2. 你非常熟悉所要引入的模式的使用场景，以及效果、代价。
你可以逆向思维：如果连需求和业务逻辑的理解都是不那么清晰和全面的话，你如何能正确地提炼出可能的变化点？如果你所提炼的变化点都是错的，那你又如何保证接口设计的稳定性？如果这些都不能保证的话，那么引入设计模式的结果一定是过度设计。过度设计的代价就是增加代码的复杂度和理解的难度。
因此，如果理解的不那么充分，就先不要引入模式，不要基于主观的臆测来提炼那些根本不需要的接口，这样十之八九是过度设计。另可在前期把程序做的简洁，然后根据需求的变更进行重构。通过重构引入模式并不是那么困难的事，而且这样做也可以尽量避免模式的误用。 --------------------编程问答--------------------
非常感谢哇！！！
你的观点应该是非常正确的，但是什么时候可以开始重构也是个值得商榷的问题呀！
你说的这种情况恐怕是非常“正规”，非常符合软件设计的原则吧！
大家想想，几个人做项目，如果这几个人不都是那么喜欢写程序的话，追求高质量、优美的代码的话，到后面还有重构的可能吗？或者说有重构的价值吗？ --------------------编程问答-------------------- --------------------编程问答--------------------
补充：.NET技术 , 分析与设计
