软件表示的是一种现实的关系，关系往往错综复杂，但是，有时内涵却是一样的。万事万物虽然形态各异，但是，宏观机械运动都符合牛顿运动定律。这种事物深层的内在联系有时候是不容易被发现的。而且，在你的软件中，很有可能没有这样统一的定律。
所以，构建一个代码的世界，更像是建筑师构筑一个大厦，而不是科学家发现定律。但，就像建筑师需要力学知识 和 美学知识，学习软件的人，也需要一些基本的定律和原则构建这样的大厦。
建筑师需要考虑客户对建筑的使用灵活性。除了主干不能变之外，房子的墙壁，里面的装修应该是可以改变的。不能一下子就把一个东西给定死了，否则价值就不能最大化。同样，软件设计也要处理这样类似的问题。
在学习了 数据结构，操作系统… 这些课程以后，你可能发现即使你学会了所有的算法，也不能灵活应用到你的问题中，最后，你会发现，大多少问题实际上是一个数学问题，你最应该学习的还是数学。你要把自己当作是一个应用数学家，而不是写代码的小蜜蜂。
建筑师有了力学知识，不一定能构建完美的大厦。而，你有了数学知识，有了完美的算法，却不一定能写一个完美的软件。你还需要处理很多细节的问题与结构问题。一般来说，它还要下面的问题：
1. 需求改变了，能不能很灵活的改动。
2. 是不是对一些边界条件上的值也能正确的运行。
3. 对输入的错误的值，是否能够有正确的反应。
2，3往往是习惯问题，养成好习惯，一般能写一个比较好的程序。但是，1能做到确是很难。
所以，有人总结了一套设计模式，用于解决上面的软件灵活性的问题。当然，软件要能构建，首先要有个符合“力学原理”问题，也就是某种关系怎么处理比较好，才不至于到了第10层楼，下面的地基承受不住了。这些也东西，有部分通用的东西也总结在了设计模式里面了。
但是，即使对设计模式倒背如流，质量很差的软件还是到处都是。关键不是背下那些模式，这些只是辅助你设计的一些东西。软件大多数时候不需要最优解，只需要可行解，应为成本才是最重要的。 或者首先要问一下自己要造几层楼。要是100层，那是一种设计方法，如果只有一层，那是另外一种设计方法。不是说，任何东西都要符合设计模式的规范。照搬照抄模式肯定不行。
首先要符合力学规范，然后是美学规范。很多人写代码，语不惊人死不休，一定要短，或者一定要用特别多的技巧，然后，只有 完美的艺术家才能欣赏他的代码。在设计的时候，不应该首先考虑用上面模式比较灵活这样的问题，或者，什么算法比较完美，先要把关系，模块，层次搞清楚，哪些是第一层，哪些是第二层。这些就是架构，它要考虑一个软件的如何合理的划分能降低建造成本。划分模块方法可以参考我以前的博文:
http://www.cnblogs.com/niniwzw/archive/2009/08/25/1553755.html
庖丁为什么能解牛，是应为他对牛的结构非常清楚，知道哪里是骨头，哪里是肉，只有弄清楚结构了，才比较好下手。结构搞清楚了，然后是一些细节架构的设计.比如，访问数据库的一个模块，你的系统有好几种数据库支持，可能要用到适配器模式。这样可以实现统一的访问接口。这样逐步求精，解决软件设计的问题。