数据不应该被直接访问

    即便是使用c语言的嵌入式开发，也不应该直接用类似p->a.b的方式访问数据。这么做一方面意味着对数据缺乏抽象，毫无设计。另一方面意味着数据存储结构和使用方式紧密耦合在了一起。当我们需要调整内存部署(以获得更好的cache亲和性以提升性能)时，代码的变更会非常困难。

避免get/set

    不直接访问，那就应该给数据访问提供接口，接口意味着隐藏实现细节，并可以延迟决策实现。

    比如写一些get/set方法。get还则罢了，set实在是很讨厌的存在。先讨论模块间。 一个模块，当然可以很多拆分的原则，大体就是几百行(一两千也行，再多就不好了)的颗粒度的那么个代码组织单元。

    get到的如果不是明确的接口，那其实就意味着别的模块对你内部数据的依赖。解决方式: 1. 明确的把它升格为模块的接口；2. 调整功能划分。当一个耦合存在让它显式存在，复杂度管理，首先是明确的抽取和度量它(什么管理都应如是)。

    至于set，如果别的模块希望改变你的内部状态，应该发个消息，不能就这么赤裸裸的写进去。如果两个模块要共同完成一件工作，比如A模块生产咖啡，B模块对咖啡进行修饰(加奶，加糖，加泡沫啥的)。咖啡就不应该是A模块的数据，而应该是一件产品(半成品)。一个产品可以在不同的模块间传递处理，但绝不能保持在某个模块那，被大家set。一言以蔽之，set就不应该存在。

封装行为:

模块间用接口替代get/set。模块内，数据的使用应该封装出具体的含义，这里说的数据肯定不是临时变量，而是有一定生命周期，表征系统记忆效应的数据。

内部数据进行一个大概分类:

配置信息，如参数，开关之类；消息触发变动，一般比较稳定；
资源；
历史值；
结果，作为输出；

数据的分类，首先是提供拆分的依据，同时也提出强制拆分的要求。拆分是管理的基础，一个系统具有一致的拆分方法才可能有一致的管理方法。

有一类模块对外界提供的服务是进行资源分配，它可以将资源的使用(申请，释放，更新等)封装成基本操作，再根据配置信息，或历史值 再封装一层定义为资源在不同场景下的操作。

封装行为的意义在于，在这个或这组数据提供的访问方式之外，数据没有别的访问方式。同时，这种封装应该具有业务层面的含义。这样代码可以更加贴近和直接反映业务。某种程度上，封装行为，是依据业务要求的接口进行编码。