适配器，“迫不得已”是你的宿命

      最近做的一个项目，第一阶段算是结束了，下午领点钱花花，如果还要做第二期的，加钱嘞....

       技术方面关于设计模式还是小有收获的，尤其是适配器模式，迫不得已用上了你，当然这也是适配器模式的宿命了。

      适配器模式在详细设计阶段是不应该考虑的，它不是为了解决处在开发阶段的问题的，而是解决正在服役的项目，没有任何一个分析师会在设计的时候考虑它。

 http://wlh0706-163-com.iteye.com/admin/blogs/1178860。原理讲解推荐博客。这里只分析下项目中使用该设计模式的原因和过程。

（ 贴张图，只是为了增加说明的方便，应该不会泄漏什么）

      最初，需要做的接口：传入的参数是某个容器如List或其他，容器存放的是用户的数据。

      后来，我们需要增加另外一个功能：保存所有数据。

      现在分析下当前的处境：用户传进来List<用户数据>,我们内部需要根据用户数据做出各种处理，包括增加各种属性像用户拖动了“活动”（参见上图），改变了滚动条的值。这些都需要保存到磁盘中，并非单纯的一个List。

      一个可行的办法是：将每一个属性按照某种特定的顺序读进磁盘保存，打开的时候再按照该顺序读出来，但是这样扩展就很难了，如果以后再增加某个属性需要保存，那么需要重新改写读写的函数，而且从本地磁盘读取出来的时候必须按照特定的协议读出来，显然过程很繁琐。

      另外的一个方法就是使用序列化功能，将某个类序列化，以二进制形式保存这个方法比较好。至于序列化，只需要知道，你只要实现Serializable接口，就可以使用系统的方法，以特定格式读写进磁盘。但是它只接受类，单个属性是不能序列化的。

      于是，当前的情形是：甲方提供了各种需要保存的数据，乙方提供了可以保存的接口方法。但是有个门槛就是，乙方只是接受序列化的类，而甲方能提供的是很多单个的属性值。于是这个时候，就需要到了适配器。该适配器，具体来讲就是：该类是一个实现了Serializable接口的类，同时以甲方提供的数据作为属性值。

 

      （语言应该不是问题）

      这样的话，自己写的类UserData就是一个适配器，想要扩展的话也是很容易地。用上了才觉得设计模式果然是不错嘞......

 

 

评论

1 楼 simhashing 2012-04-19  

学习了哦。。。