(特价书)Android开发三剑客——UML、模式与测试

第4章 针对接口编程 112
4.1 针对接口编程——问世间情为何物，直教人生死相许 112
4.2 Android与针对接口编程原则 117
第5章 设计原则 122
5.1 单一职责原则——乔峰VS慕容复 122
5.2 开放封闭原则——孙悟空任弼马温一职 127
5.3 里氏代换原则——法海捉拿白蛇新解 131
5.4 迪米特法则——慈禧太后为何不和陌生人说话 137
5.5 合成聚合复用原则——刘邦VS韩信 152
第6章 设计模式 160
6.1 简单工厂模式——一见钟情的代价 160
6.2 工厂方法模式——让麦当劳的汉堡适合不同MM的不同口味 167
6.3 抽象工厂模式——MM的生日 173
6.4 单例模式——你是我的唯一 181
6.5 原型模式——肉麻情话 187
6.6 建造者模式——让我们同居吧 192
6.7 装饰模式——见MM的家长 198
6.8 外观模式——MM也迷恋炒股 204
6.9 享元模式——短信可以这样发 211
6.10 适配器模式——笔记本电脑的适配器 218
6.11 代理模式——QQ聊天机器人 227
6.12 桥接模式——最重要的是有一颗让MM快乐的心 238
6.13 组合模式——MM的生日礼物 243
6.14 模板方法模式——人的一生应该这样度过 251
6.15 观察者模式——GG在MM身边有两个妹妹 258
6.16 状态模式——在一天的不同时间要给MM发不同的短信 263
6.17 策略模式——帮助MM选择商场打折策略 269
下篇 测 试
第7章 Android中的单元测试入门 276
7.1 Android中的单元测试初体验 276
7.2 Android中的单元测试的必要性 281
7.3 Android中的单元测试的框架JUnit 281
7.4 剖析我们的第一个单元测试程序 284
第8章 Android JUnit测试的生命周期 289
8.1 JUnit用例生命周期分析 289
8.2 JUnit用例生命周期实战 289
8.3 JUnit测试用例不向测试框架抛出异常该怎么处理 302
第9章 Android单元测试案例实战 305
9.1 测试数组 305
9.2 测试堆栈 313
9.3 测试文件系统 331
9.4 如何测试private方法 339
第10章 Android中单元入门测试 345
10.1 测试套件TestSuite 345
10.2 自动化测试实战 345
第11章 JUnit与模式 360
11.1 JUnit与模板方法模式 360
11.2 JUnit与适配器模式 362
11.3 JUnit与组合模式 369
第12章 JUnit源码剖析 370
12.1 以TestCase抽象类为核心剖析Junit源代码 370
12.2 以TestSuite类为核心剖析Junit源代码 397
附录A 如何成为Android高手V2.0：结合云计算和智能终端、软/硬件整合 408

.　　·情境：在特定情境下反复出现的情况，要求使用模式必须分析清楚事实；
　　·问题：一般来说，就是你要实现目标或要解决的目标；
　　·解决方案：典型的、通用的解决方案，应是引入深思和举一反三的解决方案。设计模式是被发现的，不是被创造的。
　　设计模式来自哪里?当然是来自人类和宇宙相互的作用。它是人类长期为追求更加美好的生活而获得的经验和智慧的结晶。
　　其实，模式理论的基本思想起源于中国。每一个炎黄子孙的身体里都流淌着模式的血液。模式充斥于中国历史和现实生活中各个方面，无孔不入!
　　《孙子兵法》中到处都是模式，当然也包括设计原则。“置之死地而后生”就是其中的一种模式，三十六计中的“美人计”、“欲擒故纵”都是模式。现在这些模式都成了古今中外各行各业研究学习的对象。据说美军攻打伊拉克的时候就使用了《孙子兵法》中的很多战争模式。
　　中国古代的法律中有很多部分都是遵循案例法的，无独有偶，现在欧洲国家一般也采用案例法的形式。所谓案例法，其基本意思就是在解决现实问题前先研究一起案例，根据现实情况举一反三，快速而准确地解决现实问题。
　　医学中也是如此，如扁鹊的“望闻问切”。望，指观气色；闻，指听声息；问，指询问症状；切，指摸脉象——合称“四诊”。“望闻问切”是中医看病的一般步骤。这是不是很像模板模式呢?
　　爱情作为一个古老而常青的话题，被人们创建出了无数的模式，不必说卓文君带着司马相如私奔，不必说梁山伯与祝英台的可歌可泣，更不必说现在各种感情剧的的流行，但就通过无数人迷恋牵涉情爱的网络游戏就可见一斑了，几乎所有的人都想成为“她”的救世主。大家更熟悉的就是郎才女貌模式、英雄救美模式，等等。而且歌手阿杜为了找到爱情的永恒模式，竟说自己翻破了爱情的秘籍，最后找到了四个字“坚持到底”!不知道这个“坚持到底”是否真的有用。但是在实现梦想中“坚持到底“的模式是绝对重要的，深度决定高度和广度嘛!只要你能坚持到底，甚至“跪着生”，最后可能也会像马云一样“拿望远镜都找不到对手”。
　　比尔·盖茨曾说过，他对员工的控制只会加强，永远的掌控，让员工在图灵面前哭泣吧。而在网络上听到关于微软软件开发过程的介绍中，其中非常重要的就是遵循绝对严格的步骤，这些都是模式。当然微软对创新是比较宽容的，这或许是为未来寻求新的更好的模式吧。
　　既然我们生活中的各个方面都存在着模式，或者说我们生活的一切都是按照模式运行，我们是否可以到处套用模式，模式不就是为了套用的吗?呵呵，当然不能随便套用!必须在合适的情境下，针对合适的问题才能采用，要实事求是。如果不考虑使用场合，随便套用看病的模式，那医院就没有存在的必要了，生病了去“Google”一下不就好了吗?可是事实上不是如此，要懂得辨症用药!三国演义中的马谡随便套用了“置之死地而后生”的模式，签下了军令状，几乎导致全军覆没。结果自己被砍头，如果不是诸葛亮仁慈，恐怕他妻儿也难逃死罪。
　　不过也感谢这些对模式不合适应用的现象，这产生了反模式——对产生绝对负面结果的问题的一种常用解决方案，旨在通过向人们展示如何避免常见的陷阱来解决问题的另一半。当然诸多模式也可以联手，如开发中如日中天的MVC模式就是设计模式联合优化的一种模式。当然，准确地说，MVC不能说是设计模式，因为MVC划分的维度过大，MVC属于架构模式。
　　在模式中，在一些比较重要的场合或者一个比较重量级的书中，你可能时不时地听到“力”这个关键字，不要被“力”搞糊涂了!按照笔者的理解，“力”是实现目标的约束条件，这种约束条件可能把你带向光明的一面——实现目标，也可能带入痛苦的深渊——远离目标。
　　其实每一种事物都是在各种力的相互作用下存在和发展或者毁灭的。正如地球的外貌是各种相互作用的结果一样，软件分析、设计、开发、测试及维护的各个阶段也都是各种力相互平衡的结果。
　　Android就是一个淋漓尽致地应用了各种模式的系统，如FacadePattern、监听器模式、适配器模式、单例模式、代理模式，等等；正是由于这些模式的应用，为Android增添了无限的风韵，也支撑了Android自身的开放性。
　　3)下篇对Android开发中的测试问题进行了详细的阐述
　　JUnit的口号：KeepthebargreentOkeepthecodeclean。
　　(1)单元测试只是证明你没有错，但并不能够证明你是对的；
　　(2)要想最大程度地证明你是对的，必须精心设计和编写测试用例(Test Case)，尤其要注意测试时的边界值和特殊情况等；
　　(3)单元测试主要用来判断程序执行的结果与预期的结果是否一致；
　　(4)单元测试不能够改变源代码。
　　任何规模稍大的公司，它在软件部门都至少会有两个至关重要的子部门：
　　· 软件开发部门；
　　· 软件测试部门。
　　一般而言，开发和测试是由不同的人负责的，这是传统意义上的测试。
　　随着测试驱动开发理念的发展和普及，尤其是敏捷思想的风靡，测试的重要性日益增长。
　　在测试驱动开发的实践中，先由软件开发工程师编写好测试代码，然后才编写真正的实现代码。
　　由上面的内容可知，测试是何等的重要!
　　对测试还不了解的朋友可能会感觉非常奇怪：为什么是先编写好测试代码，然后才编写真正的代码呢?一般情况下不是先编写好代码，然后才对代码进行测试的吗?如果连代码都没有编写，那测试什么呢?
　　答案：此处的测试主要指以单元测试为基础的测试。
　　单元测试是需要软件开发部门去完成的，而不是测试部门。
　　在开发软件的时候，我们通常都是多人协作去完成一个项目。既然是多人协作，就必然涉及分工，具体到每个人会完成该项目的不同部分，而且部分和部分之间会有交互关系，一个工程师要完成的部分可能需要另外的工程师提供的代码服务。
　　基于协作的团队工作，就提出一个要求：如何确保我提交给其他工程师的代码是正确的?
　　答案：单元测试。
　　对，在把自己的代码提交给项目组的其他人之前，必须编写单元测试，来测试自己所提供的接口和功能的正确性。
　　单元测试的另外一个好处：这是最好的代码使用说明书。
　　本书代码包可在电子工业出版社官网(www．phei．com．cn)下载，也可通过微盘进行下载(关注http://weibo.com/pheicombook，进入微盘下载。)扫描封面二维码，即可进入相关网址。
　　希望本书可以帮助Android应用开发工程师提高设计和测试能力，开启通往高级工程师、架构师之路。
　　王家林