Brick笔记（三）

• 引入思路

很多东西在我脑海里只是短暂停留的概念，为不至于错失不得不整理些出来供后续的参考和指导。

最首要的是Brick的中心思想。既然是不排斥任何一个第三方类库，主张无缝融合，那么必须要有这么一个思路让Brick更为顺畅的接纳第三方类库。

针对这个这里就记录一个初步方案。Brick接纳一个第三方类库主要由三个阶段的任务：集成、融合和抽象。

• 集成

对于集成简单点就是将第三方类库直接导入应用程序中，它该咋用就咋用，但这不是Brick的理想集成。Brick希望引入的同时做一个针对Brick的适配封装，这个封装可以是以Brick使者形式引入，当然如果条件允许最好是以Brick插件形式嵌入。

为Brick集成后的第三类库可以按照原有的方式继续使用，更建议按照Brick的方式使用，这对后续的改造将保持更高的兼容。

• 融合

在集成的基础上，有必要的情况下可以考虑融合。融合的条件比较苛刻，要求充分熟悉Brick工作原理和机制的同时也要求熟悉第三方类库，所以这方面的工作一般最好是由第三方类库供应商去考虑，当然这不太现实，目前来说供应商才懒得鸟瞰是否？嘎嘎，所以一般这个就只能由喜欢Brick的码砖们贡献了（/_\）。

融合后的Brick具有第三方类库功能的同时，也会摒弃第三方类库的原有实现，因为Brick会将具有独立支撑的功能模块化，这样我们很多东西就不需要重复性工作。

• 抽象

任何项目做到一定程度要想有更高的成长空间，那么必不可少的就是抽象。所以集成或融合多了的Brick如果不将这些东西给抽象化出来，那么不用怀疑美女是经不起大胖子碾压的。这个工作就是Brick的守护天使们要干的，我们要将一系列具有类似功能或同类型产品的实现抽象出一个统一的规则或API，一切遵照Brick的访问形式去适配或实现。

这样我们的使用者以后就不需要再为选择不同底层实现做不同开发而头疼了，他只需要给Brick一个媚眼：“嘿！给我一美女”，美女就来了。