框架是用来提供软件公司的软件设计质量，更好地为最终用户服务的，提高软件拓展维护的快速反应效率，跟随最终用户的变化而快速变化，让最终用户满意，提高了为最终用户服务的质量。
没有一个技术和公司甚至思想或解决方案能够解决最终用户的所有问题。
[该贴被banq于2007年04月17日 11:54修改过]
框架是用来提供软件公司的软件设计质量，更好地为最终用户服务的，提高软件拓展维护的快速反应效率，跟随最终用户的变化而快速变化，让最终用户满意，提高了为最终用户服务的质量。
框架是用来提供软件公司的软件设计质量，更好地为最终用户服务的，提高软件拓展维护的快速反应效率，跟随最终用户的变化而快速变化，让最终用户满意，提高了为最终用户服务的质量。
有的软件是设计给程序员的，比如IDE，帮助文档软件，测试软件，可以有难度，因为程序员这个群体回去研究，可是客户只关心跟自己业务相关的事情，你没有必要告诉他那么多。
同意
框架是让程序员更加听最终用户的话，就象你到高档场合消费，所有的服务生都视你为上帝一样，而程序员也应该也这样对待他的最终用户，但是不是依靠屈居尊严，而是依赖敏捷的软件技术：框架是其一。
[该贴被banq于2007年04月17日 12:03修改过]
不过就是觉得国内软件解决的问题太简单了。
中国企业善于解决，我买个东西花了多少钱，做成了东西，卖了多少个多少钱，所以我获利了多少。这是一种粗框的管理方法，这种运算我用计算器也能算出来，就是麻烦一些。可是我用计算器算不出来一块液晶板我怎样切割才能最大化，一块皮料怎样切割能做最多的皮鞋，我保持多大的库存才最解决成本又能满足客户需要。
框架中国不少了，可是上面的问题却很少有人想去解决。SAP的成功不是你录入了有多少物料，物料的编号是什么，它可以进行成本核算。这才是这个软件的核心。
我觉得你也范了一些人领域概念划分不清楚的问题，你上面认为的软件核心也就是业务核心，实际是另外一个领域知识：ERP管理知识，但管理不是软件，就象数学算法不是软件一样。
ERP管理和数学算法都属于另外一个专业领域，软件目前提供了一套科学的方法学来更敏捷准确将这些专业领域知识反映到计算机领域的途径，如Evans DDD，我建议大家看看这本书后，再来讨论，可能共同语言多些。谢谢。
[该贴被banq于2007年04月17日 14:06修改过]
如果大家觉得那个不够企业应用我可以接着给大家提点真的企业需求，而且是真真整整的实际的企业应用。
>但是并不代表DDD是解决一切问题的万能钥匙。
为什么喜欢考虑问题绝对化呢？别人强调DDD重要性，你就认为它是万能钥匙?DDD是一种方法，一种是看不见的知识。
>我想这个题目需求非常简单，也不需要我帮助谁进行数据建模吧。希望我能够看到不>使用算法的解决方案
你将一般最终软件概念和软件方法混为一谈，不错，软件最终成为代码能够运行时，必然结合其他领域知识，如算法 或管理，但是，我们不能就因此断定软件核心是那些其他领域知识。
我们需要一点点洞察力就能够明白这个道理。
DDD是一种看不见的知识，那么如何检验那？？就跟你学习了一堆屠龙技巧，可是世界上没有龙有什么用？？
如果软件不能解决问题要软件做什么？？难道企业信息化建设是为了摆着看的？？这有些说不过去吧。
这就是我说的，你以什么为核心，以用户为中心还是以你为中心，客户是衣食父母，他们的问题你不解决，你只是强调你的框架好，功能强，有用么？？
一个程序员不懂得算法就不配称为程序员，它可以不会建模，但是必须会写程序。世界服装大师没有不会做衣服的，称为架构师的基础也必须是一个程序员。
到底基础重要还是模式重要，我回答不出来，看不出哪个更重要些，我感觉都挺重要，至于学习的入手点，个人认为，还是基础。
先简单解释我所认为的基础：一个语言的基本数据类型，基本语法，也就是知道如何写代码，不会犯语法错误啦~
我这么认为的理由：以当前的社会环境，一个新手程序员，进入工作单位，所做的劳动，绝大部分（我想百分之七八十是有）都是从底层做起，一个项目的设计必然是公司内现有大牛们去完成，那些模式啊，OO啊，或许能够对我们理解大牛们的意图有帮助，不过当务之急是如何完成手头的任务，糊口嘛;即使你发现牛们的思路有问题,有几个会去质疑,即使你去找他了,有几个会和你认真讨论,大部分的牛还是真"牛"的.于是小鸟们写代码的优先度必然是 速度>正确率>质量 当然这是不对的，不过却是很普遍的，而那些编程思想与模式，往往是在工作过程中，慢慢体会以及主动学习去得到，这就是大家常说的“工作经验”，我想，大部分人还是都走的这条路，所以我觉得，从现实的就业讲，即使基础不是重要的，我们也不得不去选择基础。
学思想，那是理论，假定学好了，还是需要应用到程序中，这还是一个过程，至少我认为大多数人的悟性，都是需要有这么一个过程，并且我承认我还不如大多数...
学基础,至少我能比划两下,如此在工作时,我还是可以勉强应付的来,模式,可以在工作中学习,或许我第一个项目代码让人看了想吐,可第二个项目别人就说,哎?有点样子了
我想,对于用人单位,还是会倾向于来了就可以做点什么的人,这迫使大家都选择了先基础后思想,在这个角度来说,我认为基础是重要的,我也是这么过来的.
[该贴被gggg250gg于2007年04月17日 16:42修改过]
>看不出哪个更重要些，我感觉都挺重要，至于学习的入手点，个人认为，还是基础。
一般逻辑是这样的。
可是如果这个基础和你后来需要学习的模式在思维方式上是冲突的，怎么办？自己又跳不出原来所谓基础的限制。
这个帖子跟了这么长，但是谁也说服不了谁，好像各自在说自己的话，这个现象已经反映了两种思维的冲突，就象两个宗教派别的争论（中东现在还乱着呢）。
很有道理啊，确实有这个可能，还真没想到这一点
恩，如果是这样，确实会受到那基础的限制
看来应该这样来学习基础，学习基本语法，学习基本数据类型，学习常见算法，这样学出来的应该是“无模式基础”，我觉得在大学学的就是这些，当然后来的毕业设计已经多少涉及到了模式。
在这“无模式基础”上再去学习模式，我想就不会有偏差吧？我感觉，模式是在设计一个系统时需要考虑的，而思想也是这样的一个宏观的东西，是在设计和编写时无处不在的。而我们在学习伊始，我感觉，很长一段时间内，学的都是一些基本的技巧，都是为了理解语言本身，并不涉及到设计，这时候去学习模式，我想不会有影响。
我理解 banq 的意思是，如果学习基础，反倒对将来学习模式造成了障碍，不如直接从模式开始。
我的想法是：我所经历的学习过程，初期接触的基础教育，完全没有涉及到模式，只是单纯的基础，这种基础，对于模式的学习，是没有影响的。
一个比喻：我们开始学基础，学了直拳和跳跃，而模式告诉我们，先跳跃在出拳，原来可以打到更高
如果学习基础，反倒对将来学习模式造成了障碍，不如直接从模式开始。当然，不能睡不着觉怪床歪，关键是自己跳出来，象gggg250gg 等，包括我都能跳出来，但是还是有很多人没跳出来啊。
我在培训中碰到很多程序员问我Java中接口干什么？有的程序员学习了Java语言基础以后可以重来不用接口。
当我和他们讲解了GoF设计模式以后，其中演示了接口的魅力后，他们恍然大悟，所以，有时我想：模式至少确实应该和Java语言一起学习，甚至在其之前学习更好，这样，他学完后，就是使用C#等他自己已经会的语言也就可以工作了。
之前很多争执，其实还在关于软件的定义问题，到底软件是什么？软件质量标准有哪些？怎样将软件做得更好，也就是软件质量高？下面这个帖子是帖子质量相关话题，如果你不认为灵活性是软件灵魂或核心，那么OO等模式基础都是空的：
我们说的是基础，不是高层建筑。
我们现在讨论的是如何成为大师么？？
好像不是。我们讨论的是程序员的基础以及如何发展。
一个程序员，应当至少熟悉一门语言，然后掌握基本的算法与数据结构，这是为了他出现问题的时候知道可能是那里的问题，也是一种程序员的基本个人修养。现在很多人根本不关心算法，上来就问为什么hashtable的数据不是顺序的，让人觉得简直不可理解。有了基础以后，你不可能在局限于去写一个函数、一个Application，你要去做项目，去解决问题，这个时候就遇到软件设计的问题，不想办法解决它，你就过不去。那么对付这些的武器是什么？？应该就是建立在熟悉的语言以及算法的基础上。一个程序员想成为设计师不可能一辈子就写函数，他总要设计软件，解决客户的问题的。
再打个比方，程序员就像就像一个厨师，一开始是颠大勺，然后刀工，然后开始煎炒烹炸，最后可以自己设计出菜色。不能说一上来就交他做菜，他也许能学会，也能作出似乎好吃的菜，但是永远不能成为一个烹饪大师，他掌握不了火候，缺乏刀工的基础。现在很多人满足于我能做菜，而且味道似乎不错，而我觉得做人要有更高的追求，既然我们选择了去当程序员就去认认真真的去做，而不满足于当一个会做菜的人，而是要成为烹饪大师。
治大国如烹小鲜，难的东西其实都是有其基础的。一屋不扫何以扫天下，如果连最起码的修养都没有怎么能解决问题那？？你可以不去造轮子，但是你最起码要知道轮子是什么做的，用什么轮子更快吧。一样的宝马轿车，为什么固特异的轮胎就比韩泰的要快，要稳定那？？我承认用韩泰的轮胎也能跑，但是我们有固特异可以选择为什么要放弃那？？
我再说一遍，我对OO设计没有任何的偏见，我对于设计模式也是推崇备至，我也对如何更好解决客户问题有着强烈的欲望，我希望的是更多的人努力去攀登大师级的高峰，而不只是围绕在大师周围用崇敬的目光去看他们。