软件设计模式的意义
所有开发人员都应该接触过软件设计模式这个概念，看过《设计模式-可复用的对象软件的基础》这本书，在面试中都被问过： 你用过哪些设计模式这种问题。但很大可能也就仅此而已了。
为什么好像只能从框架中找到设计模式的应用示例，而实施项目中很少看到？
是项目太简单了，用不着；是技术人员水平太差了，不会写；以业务价值最优先，先实现功能，设计不重要；设计做的费时费力也看不到，没有绩效，没意义。
上面这些理由都是现实项目中实实在在的理由，并不仅仅是面对询问时的借口，而是很多开发人员的真是想法。无需列举各种各样的数据，以及一条条的格言来证明设计模式是多么多么的重要，能带来多么多么好的效果。即使引经据典写了很多，最终的结果可能就是屏幕上的一划而过。甚至对设计模式是否有必要学习都持怀疑太多，认为这些都是八股文，看了也就是为了面试。
下面是对软件设计模式的意义的一些个人看法，有不同看法的恳请交流和指教。
设计模式的底层思维
设计模式的是建立在面向对象的思维基础上的。面向对象设计中最重要的就是抽象和封装。设计模式的目的为了在满足需求的前提下，做到不破坏或则提供更好的封装性的同时提供扩展性，也就是常说的对修改封闭对扩展开放的开闭原则。
《系统架构：复杂产品的设计与开发》中提到系统设计的第一要点： 识别并隔离系统的稳定点和变化点，比如Linux的内核层和用户层。 很多软件设计模式的核心目的也是分隔稳定点和变化点，提供一种灵活实现变化点带来的扩展性以及不破坏稳定部分代码（不破话封装）的带来的可靠性。也就是常常说的解耦。
设计模式讲述的是特定需求场景下的某种模式，源自对系统设计的思考。 只有有了系统设计的思维，真正的去思考系统的稳定点和变化点时，才有设计模式存在的意义。如果有了这个想法，那么恭喜你，开始从纯粹的开发人员转变为系统设计师角色了。
要理解设计模式的意义，首先思维上要从开发人员转变为设计人员。
设计师和资深施工人员的争论
有一个调侃词： 反人类的设计。 指的是那些偏离了实际的实施环境的设计。如下图： 一个不透明的带刻度的杯子。
软件设计模式的意义
所有开发人员都应该接触过软件设计模式这个概念，看过《设计模式-可复用的对象软件的基础》这本书，在面试中都被问过： 你用过哪些设计模式这种问题。但很大可能也就仅此而已了。
为什么好像只能从框架中找到设计模式的应用示例，而实施项目中很少看到？
是项目太简单了，用不着；是技术人员水平太差了，不会写；以业务价值最优先，先实现功能，设计不重要；设计做的费时费力也看不到，没有绩效，没意义。
上面这些理由都是现实项目中实实在在的理由，并不仅仅是面对询问时的借口，而是很多开发人员的真是想法。无需列举各种各样的数据，以及一条条的格言来证明设计模式是多么多么的重要，能带来多么多么好的效果。即使引经据典写了很多，最终的结果可能就是屏幕上的一划而过。甚至对设计模式是否有必要学习都持怀疑太多，认为这些都是八股文，看了也就是为了面试。
下面是对软件设计模式的意义的一些个人看法，有不同看法的恳请交流和指教。
设计模式的底层思维
设计模式的是建立在面向对象的思维基础上的。面向对象设计中最重要的就是抽象和封装。设计模式的目的为了在满足需求的前提下，做到不破坏或则提供更好的封装性的同时提供扩展性，也就是常说的对修改封闭对扩展开放的开闭原则。
《系统架构：复杂产品的设计与开发》中提到系统设计的第一要点： 识别并隔离系统的稳定点和变化点，比如Linux的内核层和用户层。 很多软件设计模式的核心目的也是分隔稳定点和变化点，提供一种灵活实现变化点带来的扩展性以及不破坏稳定部分代码（不破话封装）的带来的可靠性。也就是常常说的解耦。
设计模式讲述的是特定需求场景下的某种模式，源自对系统设计的思考。 只有有了系统设计的思维，真正的去思考系统的稳定点和变化点时，才有设计模式存在的意义。如果有了这个想法，那么恭喜你，开始从纯粹的开发人员转变为系统设计师角色了。
要理解设计模式的意义，首先思维上要从开发人员转变为设计人员。
设计师和资深施工人员的争论
有一个调侃词： 反人类的设计。 指的是那些偏离了实际的实施环境的设计。如下图： 一个不透明的带刻度的杯子。
制造业中已经形成了高度的分工，设计和实施通常是分开的， 而在软件实施中， 产品研发很多情况下还是同一个团队完成设计和编码，采购软件产品或服务时，也通常是由供应商全部完成软件的设计和实施。再加上系统功能测试，最终用户看到的交付版本看起来都是满足用户需求的设计和实现。 Everything is OK!
那软件产品里面都有设计吗？答案是不一定。
很多小工坊模式的实体产品生产并不需要设计，或根据经验，或所谓的山寨就可以生产出各式各样的产品。 软件开发也一样。很多时候是由经验丰富的软件开发人员根据自身经验独自完成整个项目或功能的构建，本应该出现的设计评审往往由于项目规模和定位，甚至是由于对敏捷开发的误会，追求最快的产品迭代等各种原因而省略了（当然项目交付汇报时依然是要有设计阶段的哈）。
这里有常见争议点：在有限的复杂度下，既然程序员都能够自行完成项目，还有必要增加设计人员或者说设计流程吗？设计人员的产出有资深程序员的经验更优秀吗？
答案见仁见智的。个人认为还是必要的，软件产品尤其是企业信息化软件和实体产品的有一个本质区别：企业信息化软件是永远处于变化中的。实体产品生产出来后就没法改变了， 如果需要修改则需要重新设计， 开模。 而开模的费用是昂贵的，而且已经生产的产品也只能丢弃了，人们能看得到设计不完善带来的代价，因此通常都会有明确的设计环节，即使是再小的零件都有图纸，由车间工人按照图纸进行加工。企业信息化软件伴随着企业规模，流程以及业务的调整需要持续的变更，也因此带来了IT、软件二开等相关的工作（感恩珍贵的工作岗位）。从需求用户的角度，软件天生就应该可以持续修改的，运维和二开的开始阶段往往是可以很快满足变更需求的，也更加深了软件可以轻易修改的假象。
系统软件开发是减少混乱度的过程，所以它本身是处于亚稳定状态的。软件维护是提高混乱度的过程，即使是最熟练的软件维护工作，也只是放换了系统退化到非稳态的进程。--《人月神话》
直到有一天，维护人员发现整个产品都变成了一个“大泥球”，即使是一个看起来很简单的需求变更实施的代价都是巨大甚至是不可完成的。因此在各方决策人员的讨论下做出了下面的结论：“当前软件架构上落后了，无法满足我们的业务需求了，我们需要重新实施新的项目来满足企业运营需求”。 于是如同轮回一般开始了新的技术产品选型、供应商选择、实施、成功上线。但似乎很难回答上个产品的架构是哪里不能满足需求了。
回到上面没有看到软件设计模式的前面2个理由：
- 是项目太简单了，用不着： 这个理由当然是不成立的，但是这里强调的是作为开发人员自身思想上必须正视这种错误的观念。从开发管理和软件工程的角度，这个理由从来没有存在过。
- 是技术人员水平太差了，不会写： 这个理由是真实的，尤其是企业信息化软件人力外包的场景下，真实的编码人员往往连项目经验都无法保障，更别说能形成设计思维了。这个问题的解决不在于这些开发人员，需要有专门的leader或资深员工从编码工作中解放出来负责设计，这些角色也应该真正正式软件设计的重要性，而不仅是开发管理。如果都是一肩挑那那就寄希望于开发人员能够有设计的思维，认识到设计工作的客观存在性了。
总结
软件设计很重要，因此软件设计模式很重要，开发人员如果不知从何开始设计，可以通过先思考确定系统功能（业务）的稳定点和变化点，在结合了解的设计模式去选择最佳实践开始。
软件设计模式对开发人员实在的好处
软件设计模式是一门沟通工具，能够给开发人员带来的下面真真切切的好处：
- 模式项目协作沟通工具。开发人员的沟通语言就是模式，可以通过设计模式的去和业务、BA沟通编码的设计，当面对不够详细的需求文档时，不如使用软件设计模式来和BA讲解自己的设计思路，明确真正的需求。
- 设计模式是技术人员之间的沟通工具。设计模式对阅读开源框架源码、理解第三方产品有莫大的好处。比如：你看到了xxxxBuilder的类， 通常是构造器模式，也就明白了这个类的目的就是构造特定对象， 其他类似典型的xxxFactory, xxxVisitor, xxxAdaptor, xxxEventListener等。同理，我们自己开发的代码是如果能使用模式，遵照模式去定义类，也能够极大的提升自身代码的质量和可阅读性。
- 设计模式是汇报的工具。模式也是表达开发产出的最佳方式：契合业务需求的设计模式通常是最佳实践，能在满足需求的情况下提供更好的扩展性和灵活性，是最能表达开发产出和开发人员能力的工具。当然也能很好的向领导汇报工作。
制造业中已经形成了高度的分工，设计和实施通常是分开的， 而在软件实施中， 产品研发很多情况下还是同一个团队完成设计和编码，采购软件产品或服务时，也通常是由供应商全部完成软件的设计和实施。再加上系统功能测试，最终用户看到的交付版本看起来都是满足用户需求的设计和实现。 Everything is OK!
那软件产品里面都有设计吗？答案是不一定。
很多小工坊模式的实体产品生产并不需要设计，或根据经验，或所谓的山寨就可以生产出各式各样的产品。 软件开发也一样。很多时候是由经验丰富的软件开发人员根据自身经验独自完成整个项目或功能的构建，本应该出现的设计评审往往由于项目规模和定位，甚至是由于对敏捷开发的误会，追求最快的产品迭代等各种原因而省略了（当然项目交付汇报时依然是要有设计阶段的哈）。
这里有常见争议点：在有限的复杂度下，既然程序员都能够自行完成项目，还有必要增加设计人员或者说设计流程吗？设计人员的产出有资深程序员的经验更优秀吗？
答案见仁见智的。个人认为还是必要的，软件产品尤其是企业信息化软件和实体产品的有一个本质区别：企业信息化软件是永远处于变化中的。实体产品生产出来后就没法改变了， 如果需要修改则需要重新设计， 开模。 而开模的费用是昂贵的，而且已经生产的产品也只能丢弃了，人们能看得到设计不完善带来的代价，因此通常都会有明确的设计环节，即使是再小的零件都有图纸，由车间工人按照图纸进行加工。企业信息化软件伴随着企业规模，流程以及业务的调整需要持续的变更，也因此带来了IT、软件二开等相关的工作（感恩珍贵的工作岗位）。从需求用户的角度，软件天生就应该可以持续修改的，运维和二开的开始阶段往往是可以很快满足变更需求的，也更加深了软件可以轻易修改的假象。
系统软件开发是减少混乱度的过程，所以它本身是处于亚稳定状态的。软件维护是提高混乱度的过程，即使是最熟练的软件维护工作，也只是放换了系统退化到非稳态的进程。--《人月神话》
直到有一天，维护人员发现整个产品都变成了一个“大泥球”，即使是一个看起来很简单的需求变更实施的代价都是巨大甚至是不可完成的。因此在各方决策人员的讨论下做出了下面的结论：“当前软件架构上落后了，无法满足我们的业务需求了，我们需要重新实施新的项目来满足企业运营需求”。 于是如同轮回一般开始了新的技术产品选型、供应商选择、实施、成功上线。但似乎很难回答上个产品的架构是哪里不能满足需求了。
回到上面没有看到软件设计模式的前面2个理由：
- 是项目太简单了，用不着： 这个理由当然是不成立的，但是这里强调的是作为开发人员自身思想上必须正视这种错误的观念。从开发管理和软件工程的角度，这个理由从来没有存在过。
- 是技术人员水平太差了，不会写： 这个理由是真实的，尤其是企业信息化软件人力外包的场景下，真实的编码人员往往连项目经验都无法保障，更别说能形成设计思维了。这个问题的解决不在于这些开发人员，需要有专门的leader或资深员工从编码工作中解放出来负责设计，这些角色也应该真正正式软件设计的重要性，而不仅是开发管理。如果都是一肩挑那那就寄希望于开发人员能够有设计的思维，认识到设计工作的客观存在性了。
总结
软件设计很重要，因此软件设计模式很重要，开发人员如果不知从何开始设计，可以通过先思考确定系统功能（业务）的稳定点和变化点，在结合了解的设计模式去选择最佳实践开始。
软件设计模式对开发人员实在的好处
软件设计模式是一门沟通工具，能够给开发人员带来的下面真真切切的好处：
- 模式项目协作沟通工具。开发人员的沟通语言就是模式，可以通过设计模式的去和业务、BA沟通编码的设计，当面对不够详细的需求文档时，不如使用软件设计模式来和BA讲解自己的设计思路，明确真正的需求。
- 设计模式是技术人员之间的沟通工具。设计模式对阅读开源框架源码、理解第三方产品有莫大的好处。比如：你看到了xxxxBuilder的类， 通常是构造器模式，也就明白了这个类的目的就是构造特定对象， 其他类似典型的xxxFactory, xxxVisitor, xxxAdaptor, xxxEventListener等。同理，我们自己开发的代码是如果能使用模式，遵照模式去定义类，也能够极大的提升自身代码的质量和可阅读性。
- 设计模式是汇报的工具。模式也是表达开发产出的最佳方式：契合业务需求的设计模式通常是最佳实践，能在满足需求的情况下提供更好的扩展性和灵活性，是最能表达开发产出和开发人员能力的工具。当然也能很好的向领导汇报工作。
