【来龙去脉】
众所周知，一台最常见的PC往往由主板、CPU和各种芯片板卡(如内存、声卡、网卡、显卡等 )等组件组成。所有的组件可以分别由不同的生产商遵循确定的电气指标和接口标准并行开发和生产。生产完成后，只要按照接口要求，接驳集成在一起，基本就可以正常工作了。这是一种多么成熟且高效的生产流程啊！
反观目前的软件开发，成熟度和效率要低很多。虽然，在软件开发领域也提出并正在运用组件式的开发，但是其成熟度和效率，相比于硬件工业的效果仍旧差距显著。笔者认为重要的原因之一是很多软件组件之间存在着不必要的物理耦合(例如在代码层面指名道姓地进行调用 )，最典型的是编译期耦合。打个比方，A组件的功能，逻辑上需要依赖B组件，B以某种库的形式存在。在A的开发过程中，其编译、链接以及模块测试的运行，往往严重依赖于B的现场存在，例如需要B的头文件，或者是lib文件、dll文件、jar文件等 ，不一而足。这种物理上的耦合，牵制了AB双方的开发活动，明显降低了效率，并在耦合环节为bug的产生埋下了伏笔 。另一方面，在产品的维护上也提高了成本、降低了效率，最糟糕的情况下，甚至会造成牵一发而动全身的效应 。这是软件工业普遍存在又亟待解决的根本性问题之一。
【创新畅想】
针对这种困境，让我们大胆地畅想一下，如果软件工业可以实施像硬件工业一样的开发、生产方式，这将是一种多么令人憧憬的场景啊。我相信，这种深度解耦的模块化、分工合作、并行开发 的模式，必将是软件工业的大趋势。因此，虽然目前还没有一种成熟的思想和技术可以实现这样的场景，但我们软件行业的从业者应该始终朝着这个方向不懈的努力，使这个目标尽早得以实现。这个目标的实现，是软件工程师劳动力、创造力的解放，也是软件工业生产力的革命性飞跃。
正是基于以上的这种尝试和努力的心态，基于匹夫有责的意识，在本文中，笔者试图给出一种被称为“软芯片”(softchip) 的软件架构设计的创新思维(请恕笔者才疏学浅，这种idea早有提出也未可知 )。Softship架构设计思想的主旨是组件间深度解耦 。具体而言：
01 .在软件架构设计上，构造一种类似“主板 ”角色的基础机制，作为所有组件的支撑平台。
02 .组件间的绝大部分交互将经由这种类似主板的平台机制 (软主板softboard )来协调实施，组件之间几乎不再直接“面对面” 。
03 .基本上，每个组件模块可以独立开发、编译 和模块测试 。
04 .在软件开发过程中，存在组件开发者 和系统集成者 两种角色。组件开发者按照系统集成者制定的功能spec和接口标准生产组件，系统集成者负责制定所有组件的功能spec(概要 )和接口标准(详细、具体的 )以及组件完成后实施系统集成。
因笔者对于硬件原理和开发没有深入涉猎，以上的与硬件相关的认知仅仅是一种介于感性和理性之间的粗浅的个人见解，如有偏颇，欢迎众多业内有识之士不吝指出的同时也敬请谅解。另外，由于Python 语言的很多特性，非常天然地适合表述、展示和实施softchip的思想和技术，笔者选择了Python作为尝试和实施的平台(并非是为了赶时髦 )。因此，本文中后续出现的各处code sample，均为Python代码。这些sample代码可以确保在Windows XP(SP2) + Python 2.6 版本环境上能够成功编译和运行。
由于内容稍多，在结构组织上将以系列的形式推出。系列的第一篇(本篇 )主要是背景介绍和关键设计思想的陈述，作为读者理解后续内容的必要铺垫和引子。由于笔者仍旧需要忙于家庭琐事和开发工作，在时间上可能难以保障快速、连续地完成本系列的全部文章，敬请谅解。同时，这是笔者首次在CSDN上创建和发表技术博客，对于CSDN上的编辑环境使用方面还很不熟练，比较笨手笨脚，在各位大家面前难免显得很简陋、粗糙和不够专业，也提前敬请谅解并欢迎批评指正，笔者今后会逐步改进提高。
在本篇剩余的部分，将主要说明Softchip的设计思想。
【Softchip架构设计思想概述】
问题所在：
本文所针对的组件间的物理关联，基本上以指名道姓地进行函数/方法调用的形式发生。调用的起因是调用者的功能，需要被调用者的支撑才能够完成，这在逻辑上是合理和正常的。但是，逻辑上的关联进而演变成物理上的依赖和牵制就是问题 了。设调用者为A，被调用者为B。在编译(+链接) 期 ，A可能需要B的头文件、库文件等，在运行期 ，A往往还需要B的句柄或指向B的指针。这种编译(+链接 )期和运行期的“赤裸裸”的依赖，是问题的关键环节，也是改善方案的关键着力点 。
应对方案：
Softchip架构的中心思想：
01 .坚决 消灭编译 ( +链接 ) 期依赖 。将依赖关系 推迟到运行期 发生( 不得不发生时再发生吧 )。
02 .封着/屏蔽运行期依赖 ，由“软主板softboard ”来实施 ，组件之间不会直接面对面，基本上都与softboard交互。
组件相互之间不需要/不会意识到对方的存在 ，即使是正在使用对方的服务或正在为对方服务。组件们只知道向softboard
提出要求并 享用softboard提供的服务 或者是响应softboard提出的要求并提供自己的服务。
为实现上述中心思想，具体的手法是：
01.Softboard提供运行期API绑定 机制。
多数类似基本服务的、可重入( re-entrant 的，被调用者不需要在调用前后保持任何数据，
只需在被调用期间利用输入参数提供服务即可 )的函数/方法调用可以(或推荐 )以这种形式发生关联。
例如，A (依赖者 )需要B (被依赖者 )的整数加法运算。则在运行期，B向softboard注册 名为add的服务，
A向softboard订阅 add服务并从softboard处获得add服务的入口(类似C中的函数指针 )，在使用时只需调用服务入口并
传入指定参数即可。A不知道B的存在，也拿不到B的句柄或指向B的指针之类的东西，只有它需要的服务入口地址而已。
02.Softboard提供运行期 Event交换(switch)/分发(dispatch) 机制。
对于不适合使用API绑定机制的情况，可以利用event交换/分发机制发生关联。
假设 A (依赖者 ) 需要B (被依赖者 )处理event X 。则在运行期，A向softboard注册 为X的生产者 ，B则注册 为X的消费者 。
softboard在所有的event生产者和消费者之间充当一个类似event交换机 一样的角色，每当生产者生产出event X
之后，就投递给softboard，而softboard根据event的dispatch关系表，查阅 并分发 给实际的消费者(也可能有多个 )。
根据event的性质，每次的event分发/交换过程可以是同步 的(生产者等待event处理完毕 )，也可以是异步 的(生产者不等待 )。
上述大意，以如下草图演示：
通过以上的运行期API绑定和Event交换两种手法，编译(+链接)期的耦合不存在了。在运行期，所有组件都在
与softboard这一层次进行着交互，softboard就像红娘一样穿梭在依赖者和被依赖者之间，牵线搭桥。即使是依赖者
调用了被依赖者的API或event handler，也对对方的存在毫无意识，因为真实的关联都发生在softboard的幕布之后。
所有的组件都像是插在softboard的上的一个个的chip，是board上隐藏的线路暗地里传递了控制或数据。而所有的chip
都是自由的，它只知道一件事情：“我插在board上，我为board服务，board也为我服务”。
在后续的篇章中，将逐步细化softchip架构设计的各部分细节并使用Python的sample code
来展示实际的场景和效果。大致的结构划分是：
第二篇：Softchip的运转场景：基于API绑定和Event分发的组件设计与实现。
第三篇：API绑定和event分发机制的设计与实现。
第四篇：Softchip框架设计思想所具备的优点和面临的课题。
OK，本系列第一篇到此为止。感谢大家的关注！
Michael
2010-04-18 凌晨于上海。
注：对此系列文章感兴趣的同道，可以使用Email联络：micblues@126.com
167
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
