fpcc的专栏

一定要明白状态机的目的和作用，要学会在不同的场景和条件灵活的使用状态机。一般情况下，状态机的设计不要过于复杂，这样不利用状态机的维护。同样过于简单的情况也不一定非得要用状态机。至于如何避免复杂，就记住一句话，拆分状态逻辑，利用中间层处理。状态机和其实现的方式，其实都是重点，重点在于如何将状态机与实际的实现逻辑严格的对应起来，保证状态的稳定和准确，特别是不能忽视某些特定条件的状态转换及行为的细微差异。只要能把握完整的状态流程，状态机的实现也就是一种代码的展开罢了。

目前，智能驾驶这个赛道火得很，但其中的车联网系统中就广泛使用了这种机制。所以说，掌握好原理才能更好的拓展一项技术的应用，而不只是机械的模仿。需要说明的是，本篇不是分析发布/订阅机制内部实现的文章，而重点在于将其如何应用于设计当中。尽管篇幅不大，但希望给大家一个另外的角度做为切入点，也就是说，要从不同的角度来看待一个技术问题，才能更好更全面的明白其在整个技术框架中的作用。

推和拉本身不难理解，也易于实现。但麻烦就在于实际应用场景中的复杂度和各种异常的处理，这才是重点中的重点。所以大家一定要根据实际情况进行平衡，保证所需。而不是为了应用推拉去实现推拉机制。

本文主要是给不了解或者想学习事件机制的开发者一个入门的方法，重点在于提供一个初窥门径的视点。在明白了事件机制的原理后，可以根据自己的技术水平的增长和认知思想的不断提高，设计出一个相对更完善更合理的事件系统。万事开头难，临门第一脚。以后有机会在此基础上将一个相对事用的事件系统给大家剖析一下，那么就更容易在事件系统上总结提高。愿与诸君共勉！

本文不是讲虚拟内存技术本身或者说其技术的特点。重点是讲述为什么会存在虚拟内存，这是给后来开发者或者说设计者的一个解决问题的思路。活学活用别人的思想，真正领会这些技术架构的思想并学习和吸收成为自己的思想，才能更好的解决面对的问题，进而从整体上提高自己的技术。最后，技术的发展，不是凭空想象的，它一定是实际需求推动的。所以理论和实践相结合，是重中之重！

程序的开发，往往不是一两个因素影响，而是一个多重的因素整体互相影响确定的。而一个优秀的设计者就是要在这些因素中，找到关键的因素，也就是常说的主要矛盾，并处理在某些情况下，次要矛盾转化为主要矛盾时如何处理（比如程序异常时，保存了部分的文件怎么办）。所以，有丰富的理论和实践形成的指导思想，才是解决问题的关键所在。好医生是在病患未起时就将其消灭。也就是所谓的预防大于治疗。而目前看来，在软件开发中，仍然是以“治疗”为主。希望开发者们能尽量把重心前移，减少亡羊补牢的情况！

爱看武侠小说的知道有形意拳这个拳法，形和意，一外一内。而在武林中又有一句话“练拳不练功，到老一场空；练功不练拳，到老也枉然（犹如无舵船）！其实编程也是如此，光明白理论，不进行实践，那么进步就无从谈起；反之，光进行实践不学习理论，则方向无法把握，事倍功半。前面反复提及，计算机编程是一个理论和实践高度结合的技术，理论和实践是互相促进互相发展的，请大家务必明白这一点。既要扎实的推进编程的水平，又要不断的多看一些英文的资料紧跟技术发展的潮流和方向。

简单的东西，往往意味着灵活。因为简单，所以应用的广泛，应用的广泛就意味着应用的场景丰富。不同的场景下的应用就有可能有细节的不同。而细节的丰富恰恰是C++的一个特点，也是为广大开发者觉得不容易把握的地方。作用域看似简单，但它和代码编写直接结合了起来。往往代码的水平就可以通过作用域的控制窥见一斑。而作用域还有一个特点，即使设计的较差甚至非常差，在一些中小程序中对程序的运行也不会有什么影响。往往就会让大多数中低程序员将其忽视。简单不代表容易把握，切记！

勿在浮砂筑高台。只有掌握技术本身，才能更好的在设计上展开应用。换句话说，一个优秀的设计者本身必须是一个优秀的开发者。这也是前一段时间网上经常说的所谓“PPT架构师”的味道。知其然并知其所以然，顺势而为，才可能有一个优秀的设计出来。

学习设计就是从这些小的基础的东西一步步走过去的，不要妄想着上来就指挥千军万马并且打胜仗。甘罗八岁拜相，不谈真假，但几千年出不来几个。回头看看世界军事史，有名的军事家都是一枪一枪打出来的。没有人天生就是元帅。软件设计亦是如此，实践出真知。

设计的学习难度说大很大，说小很小，关键看开发者的知识驾驭程度和水平。条条大路通罗马，但有没有捷径，这种捷径是否适合每个开发者？是不是有更适合具体到某一个人的捷径？这就需要每一个开发者和设计者不断的探索。总体而言，多学习理论知识，多写代码，多看优秀的开源代码和框架，多和优秀的设计者进行有效的交流。在此基础上不断的思考和实践，对大多数开发者来说，是一条不错的提升之路！

设计一个从抽象到具体，从整体到细节，不断具体而微的过程。俗话说得好“教的曲儿唱不得”。设计不像技巧，多问两下多看两下代码就会用了。所以设计中的一些具体的手段和方法，要不断的从不同的角度不同的场景进行分析学习，并不断在实践中进行检验。反思得失，总结教训，形成自己的一套解决问题、处理问题的逻辑和流程。最终升华为自己的设计思想。这一定是一个长期的，不断的否定之否定的过程！愿与诸君共勉！

一种技术如果不放到具体的场景中，谈不到优与劣，更谈不上对与错。技术的出现就是为了服务于现实的需求，如果脱离开这种需求技术的意义就没有多大了。如果实际的网络需求永远不会超过100K，那么光纤就可能不会被应用到网络传输上。合适的是最好的，但要明白，这个合适是动态发展、不断变化的。与诸君共勉！

在设计的过程中，最主要的目的就是实现“高内聚低耦合”。其实不耦合是最好的，但正如人是群体性动物一样，不和别的人发生各种关系是不可能的。而把这种发生的各种关系移植到代码上，就可以称之为依赖。这种依赖越少，就说明耦合程度越低（即解耦）；反之则耦合程度越高。高内聚则是指，单元（一个函数，一个类等都可以是一个单元）内功能的依赖关系越紧密越好，也可以理解为相关功能关联度越紧密越好。

设计是一个不断沉淀的过程，没有人可能一下就掌握了设计的全部精髓。这就和一个人的成长一样，从婴儿到成为一个健硕的青年，中间可能会经过无数的大大小小的错误，既有身体疾病上的成长的过程，也有思想不断成熟的过程。所以，设计只是一个人思想的外延。它既受主观的影响也爱外面客观的实践的影响。

接口的应用是极其广泛的，即使没有任何开发经验的初学者，可能第一个程序都会遇到接口的调用。一个开发者既要明白接口是什么，又明白常见的API和接口有什么关系。既要学会使用别人的接口，又能很好的设计自己给别人提供的接口。只有掌握了接口的真正本质，才可能适应在不同的场景接口的应用！

软件设计不光是技术的问题，纯技术流往往会产生一种唯技术论的现象。软件的设计是一种现实与计算机交互融合的过程，往往涉及到技术之外的经济性、效率性、公平性等等具体的社会问题。软件设计是把软件的实现与实现世界结合起来，服务于现实世界，而不是一种独立存在。要始终明白，实际的需求才是软件技术发展的根本动力！

代码复用除了从设计角度看，其实也可以从重构的角度来看。重构的一个重要目的就是减少冗余代码，那么做好代码复用当然冗余就会大幅降低。所以说，一件事，如果从不同的维度和不同的应用方向来看，就会有不同的效果。这就又回到文中的“编程思想” 了，思想是什么？其实就是现实抽象的结果。

前面提到过封装和相关设计的一些分析，在它们的实践的过程中，解耦其实就已经悄然的不请自来。面向对象开发中最重要一个方法是封装，可封装的优劣如何判定呢？其中一个重要的方法就是看封装的耦合度。解耦就是封装一开始就必须考虑的问题。设计和开发实践是体现开发者解耦能力的一个验证器。而将解耦设计好与坏，可能在当下并不会产生多大的效果，但在二次开发和完善修改时，就会发现，解耦的重要性。人教人很难学会，事儿教人一次就会。一个道理！

这篇文章不是教大家怎么绘制这两类图形的，因为这种资料太多了。这里主要是对其中的不同和应用的细节进行对比说明，这样让大家在实际的设计应用中不会混淆。主要是起一个借鉴和随时拿来做个参考的内容。

简单和复杂是相对的。简单是外在的，复杂是内在的。所以开发者要有追求简单的目标，但不能为了简单而舍弃所有，也不可能舍弃所有。总说的一句话，简单是王道，就是这个意思。无论是开发还是设计，都要善于从复杂走向简单，抽丝剥茧，实现从混沌到清晰！

这篇文章是有感而发。里面大多是一些实际的应用而不是技术的分析，大家可以见仁见智，批评讨论！

原则的使用，是思想指导实践的过程的准则。它不光是一些干瘪的词汇，更是很多前辈总结出来的经验教训。如何能够灵活的运用这些原则来指导自己的开发，就看开发者自己对这些原则领悟的的深度了。“尽信书不如无书”，经验主义和教条主义害死人。开发者一定要真正的从思想上升华，进而灵活的运用这些原则，才是正理。

Resource Acquisition Is Initialization，资源获取即初始化。C/C++的开发者都知道，在这类语言的开发中，内存需要手动来控制。也就是说，释放和回收内存得开发者亲历亲为。从某种角度看，能够把控内存的细节，当然是更灵活，可如果把控的不好，却是一场灾难。根据二八定律，对于绝大多数的开发者来说，都被划分到了灾难的一个方向（即使经验丰富技术高超的开发者也难免会出问题）。那么，尤如医学上所讲，预防大于治疗。在C++中，哪些对象的生命周期是不需要自己控制而由系统自动控制呢？

虽然在书籍上和网上有很多设计模式的特点，比如什么面向对象编程思想，可维护可扩展等等。其实就这是前面说的，说得高大上而已。一个简单就代表了可维护性，暗含了可扩展，简单的东西本一般来说容易扩展，而复杂的东西，理解都需要很长时间，怎么容易扩展？同样，简单可重复的东西自然就灵活，其它情况也基本如此。学习，要抓住问题的本质，不是说其它的东西不重要，而是抓住本质后，再学习其它的特点，就非常容易弄明白和记清楚。

再次提醒，不要轻易展开优化。特别是对于一些中小公司的开发者来说，不要迫切的想优化你的项目。可能开发者的优化并不是设计者想优化的目的。同样，技术人员的优化可能并不是市场人员的优化的目标。说来归去，实事求是的根据实际需求进行优化。盲目的优化，有可能会让你盲目。

在现实世界里，经常会看到一些现象。举一个简单的例子，自己的家里可能时间久了，觉得家俱的摆设、风格或者位置等会动一动。如果觉得整体的家庭的环境都不太喜欢了，或者说让居住者不舒适了，还可能找人重新装修。这就可以理解成重构。它是对房屋内部的装饰的一种重构。当然，如果整个房子有些老旧，甚至可能有些年久失修的风险，但发现房子的基础和墙壁大梁等还挺结实，那么也可以再次在此基础上进行加固或者拆除不好的部位重新换上新的部分。这也可以理解成对房屋的重构。那么有人会问，如果房屋需要推倒重建呢？那就不是重构了，那是再建。

人难得是选择，选择是最痛苦的。但一旦选择完成，朝着方向前进，其实反而没有什么可痛苦的了。今天讲协程，没有继续于以往的技术实现的原理和实现的框架或者应用的方法，而是从另外一个角度分析其在计算机发展过程上的定位。言简意浅，与诸君共勉！

其实队列的处理，不光有这种细节需要处理，包括内存大小的处理，是否提前处理，都是需要考虑的。正如前面所说，一个队列的设计，不仅仅是一个算法的问题，可能涉及到很多的技术知识和相关的难点。如何能够综合运用这些知识适配开发场景，就是对设计师的一个考验了。

面向对象编程是一种非常广泛的编译方式，很多开发者可能对它是既了解又不了解。对一些基础的知识会用，但又不知道是否用得合适，能不能有一个标准来判定。其实这恰恰表明对面向对象编程还是掌握的不够深入。一切设计没有标准只有原则，这也意味着，实际场景下，在考虑原则的同时，更要考虑实际的需求进行适当的取舍。最好的设计方法是没有的，只有最合适的设计方法。

架构设计和思想这些东西，是非常不愿意谈的。一个是网上和实际的书本上资料太多；而另外一个就是，这些东西是需要大量的编程实践来支撑的（这也意味着不同的环境发展可能产生不同思想体系）。换句话说，对一个没有任何编程经验或者说编程经验少得可怜的人来说，谈这些根本没有任何意义。那么有人说，我好好的编程，搞这个十几年，不就有了架构和设计的思想体系了么？大错。编程经验是架构设计的一个必要条件而已。大家都明白道理，但是一真正涉及到自己，就拎不清楚了。

对绝大多数软件人员而言，其实很多技术拼到最后不是拼设计者的聪明才智，拼的是经验。特别是对于工程类的开发更是如此。而软件开发领域，基本以现有的成熟的技术为主，这点就更突出。随着软件的规模越大，经验的要求越高。很多开发者可能终其一生都遇不到所谓的千万并发，那希望他设计一个支持千万并发的服务，就是一个不可能的任务，其它情况亦是如此。所以开发者们勿需气馁，把基础打好，认真学习，找机会就上。不断总结经验得失，技术就会越来越磨炼得精粹。

在分析完成数据结构的封装后，基本也就明白了在多线程中如何使用STL中的容器。但是，一般对线程安全的操作控制，都是使用锁。不管锁的粒度是大是小，对性能的影响一般来说都是比较大的。而多线程特别是线程池恰恰又都是在高性能的场景下应用，所以这时就需要开发者认真考虑加锁引起的性能损失。当然，在后面可以考虑在某些情况下使用无锁编程技术，让数据的处理更快捷。但无锁编程也不是万能的，它也是有其相对的应用场景。万流归宗，还是需要开发者对整体技术的把握和实际应用场景进行综合考虑。

数据通信模型和多线程编程本身是密不可分的，原则上来讲，谈及多线程编程一般就是要实现多线程之间的通信，否则多线程技术本身并没有什么可讨论的。一个技术其实如何能真得可以深入掌握进去，其实就是一个生态，围绕着它或近或远或紧密或间疏的有着各种各样的其它技术与之互相配合。挨过来一样，在其它的技术上，可能学习的这个技术又是其生态中的一环。明白了吧，你中有我，我中有你，这才最终形成了更广义上的计算机技术。

在目前可预见的技术范围内，完全无锁的可能性几乎是零，而且相对于有锁编程，无锁编程的要件有点多，这也导致无锁编程更多的应用于基础层。而且大多的应用场景其实对于效率的敏感性并没有到不可忍受的地步，所以这也是HA/HS应用非常广泛的原因。大家可以看看这篇文章“An Architectural Pattern for Efficient and Well-structured Concurrent I/O”，会有更好的体会心得。

学习理论就是学习别人抽象出来的知识，然后再把学习到的知识理论应用到自己的工作中。如此往复循环，慢慢就会对这些知识有了更深刻的理解，也就可以在此基础上自己抽象自己的理论和知识体系来指导自己的实际工作。武林中不是有一句话：“练拳不练功，到老一场空；练功不练拳，到老也枉然！计算技术亦是如此。

DDD整体设计应用的流程和方式

对DDD领域驱动设计听 柔性设计进行分析说明

对元编程中的策略设计进行分析说明

对c++中的类型擦除的应用举一个例子的演进说明