摘要: 异常处理的关键在于何时处理异常以及如何使用异常,有些开发者会觉得try catch的处理和使用难以把握,于是他们秉承着“您可错杀一千,不可放过一个”的想法,给所有的方法添加try catch。 从用户角度出发,用户确实难以察觉到什么,应用程序运行正常,使用的体验好像也没什么差别。 从程序角度出发,大量的try catch会降低代码的可读性,只有在异常触发时才会对程序的性能造成较大的影响... 阅读全文
posted @ 2016-05-21 05:44 keepfool 阅读(1459) 评论(8) 推荐(10) 编辑
摘要: if else, for, while等是程序中最常用的语句,这些语句有一个共同点——它们的逻辑都封装在一对“{}”包围的代码块中。在实现复杂的业务逻辑时,会较多地用到这些语句,可能会形成多层的代码嵌套。代码的嵌套层数越大,代码的缩进层次就越深,这将会降低代码的可读性。本文要讲的“分解大括号”策略正是为了避免这种问题,它也可以使我们的代码变得更加整洁。 阅读全文
posted @ 2016-05-20 22:59 keepfool 阅读(1398) 评论(2) 推荐(7) 编辑
摘要: 代码是从命名开始的,我们给类、方法、变量和参数命名,我们也给解决方案、工程、目录命名。在编码时,除了应该遵守编程语言本身的命名规范外,我们应该提供好的命名。好的命名意味着良好的可读性,读你代码的人无需太多的注释,就能通过名称知道它是什么,它能做什么事儿,以及它应该怎么用。我们命名、命名,不断地命名。既然有这么多命名要做,我们不妨做好他。 阅读全文
posted @ 2016-05-20 07:26 keepfool 阅读(1264) 评论(8) 推荐(13) 编辑
摘要: 在程序中创建对象,并设置对象的属性,是我们长干的事儿。当创建对象需要大量的重复代码时,代码看起来就不那么优雅了。从类的职责角度出发,业务类既要实现一定的逻辑,还要负责对象的创建,业务类干的事儿也忒多了点。对象创建也是“一件事”,我们可以将“这件事”从业务代码中提取出来,让专门的类去做“这件事”,这就是本文要讲的主题——提取工厂类。 阅读全文
posted @ 2016-05-19 23:49 keepfool 阅读(1009) 评论(3) 推荐(8) 编辑
摘要: 试想这样一个场景,你提供了一些API给客户端调用,客户端传入了一些参数,然后根据这些参数执行了API逻辑,最终返回一个结果给客户端。 在这个场景中,有两个隐患,它们分别是: 客户端调用API时,传入的参数是否准确,参数是否满足API的执行前提 API逻辑执行完时,返回的结果是否准确,结果是否符合客户端的预期 阅读全文
posted @ 2016-05-19 07:15 keepfool 阅读(1491) 评论(2) 推荐(5) 编辑
摘要: 在一些较为复杂的业务中,客户端需要依据条件,执行相应的行为或算法。在实现这些业务时,我们可能会使用较多的分支语句(switch case或if else语句)。使用分支语句,意味着“变化”和“重复”,每个分支条件都代表一个变化,每个分支逻辑都是相似行为或算法的重复。今天我将介绍一种新的处理“变化”和“重复”的策略——“使用策略模式代替分支"。 阅读全文
posted @ 2016-05-17 22:42 keepfool 阅读(2481) 评论(8) 推荐(18) 编辑
摘要: 有时候你可能会在条件判断中,根据不同的对象类型(通常是基类的一系列子类,或接口的一系列实现),提供相应的逻辑和算法。 基于这种场景,我们可以考虑使用“多态”来代替冗长的条件判断,将if else(或switch)中的“变化点”封装到子类中。这样,就不需要使用if else(或switch)语句了,取而代之的是子类多态的实例,从而使得代码的可读性和可扩展性提高了——这就是本文要介绍的重构策略“使用多态代替条件判断”。 阅读全文
posted @ 2016-05-15 17:08 keepfool 阅读(3946) 评论(2) 推荐(9) 编辑
摘要: 我们有时候在应用程序中可能编写了一些“幽灵”类,“幽灵”类也叫中间类。这些中间类可能什么事儿都没做,而只是简单地调用了其他的组件。这些中间类没有发挥实际的作用,它们增加了应用程序的层级(layer),并且增加了应用程序的复杂性。这时,我们应将这样的中间类删除,甚至删除中间类所处的“中间层”——这就是本文要讲的重构策略“移除中间类”。 阅读全文
posted @ 2016-05-15 10:32 keepfool 阅读(1009) 评论(0) 推荐(4) 编辑
摘要: 为了方便大家阅读这个系列的文章,我弄了个目录汇总。主要包含4个部分:1. 方法、字段重构 2.类、接口重构 3.设计模式重构 4.一般性重构 阅读全文
posted @ 2016-05-14 15:32 keepfool 阅读(4363) 评论(2) 推荐(14) 编辑
摘要: 有些开发者为了贪图简便,看到一个现成的类,也不管这个类是做什么的,需要追加功能时,就向这个类里面添加功能代码。久而久之,使得一些类变成了“上帝类”。什么是“上帝类”?上帝类也叫万能类,意指做了太多“事情”的类。在开发过程中,我们应该保持一个良好的习惯,在类中追加功能时,一定要事先确认类的职责,并控制好类的粒度,这有益于代码的可读性、扩展性、维护和修改。 阅读全文
posted @ 2016-05-14 15:19 keepfool 阅读(3955) 评论(0) 推荐(5) 编辑