消息提示的架构演进-理论篇（转载）

消息提示内容的硬编码。多个相同类型是消息（例如提示操作成功），如果变更这个类型提示的内容，需要在很多地方修改，几乎苦不堪言。消息框的初始化是散落在各个和后台交互的地方的，如果需要变更一下消息框的UI，也会造成需要多个地方的修改，已经苦不堪言了。消息的逻辑代码和UI显示代码是混合在一起的，没有分离，导致无法单元测试。

首先，将消息分类，方便后面的处理。对于硬编码的问题，根据类型，将相同类型的内容集中管理，达到复用和便于后期维护的作用。集中管理消息框的初始化工作，也可以方便消息框UI的变更，可以通过引入工厂模式来解决。分离消息的逻辑和UI显示代码，方便单元测试和UI的变更。建立一个消息中心，集中管理消息框的初始化，以及消息的显示。

消息处理的独立消息处理的公用分离消息处理的逻辑和消息内容的UI显示消息管理的集中

?

?

　　经过整理，消息大概分为下面的几类

成功。正确完成一次请求。提示。在完成请求的过程中，缺少必要条件，或者是某些条件发生变化，导致不能正确完成请求。异常。在完成请求的过程中，发生了异常，包括：代码异常，网络异常等等。

?

?

?　　在后面的实现中，准备引入面向接口的编程，将消息中心和消息的处理接口化，方便将来的替换。消息框的初始化引入工厂模式，实现初始化的集中管理，隔离消息框（标题，提示内容，按钮，按钮的操作）和消息框UI显示，为将来的UI变更预留空间。

　　今天先讨论到这里，关于实现以及代码会在后面几篇分开讲解。

　　大家如果有什么更好的建议，可以在后面留言给我，感谢大家的参与！！！

?

?

?

文章来源：http://www.cnblogs.com/virusswb/archive/2011/10/12/2208417.html