摘要:
异常处理的关键在于何时处理异常以及如何使用异常,有些开发者会觉得try catch的处理和使用难以把握,于是他们秉承着“您可错杀一千,不可放过一个”的想法,给所有的方法添加try catch。
从用户角度出发,用户确实难以察觉到什么,应用程序运行正常,使用的体验好像也没什么差别。
从程序角度出发,大量的try catch会降低代码的可读性,只有在异常触发时才会对程序的性能造成较大的影响... 阅读全文
摘要:
if else, for, while等是程序中最常用的语句,这些语句有一个共同点——它们的逻辑都封装在一对“{}”包围的代码块中。在实现复杂的业务逻辑时,会较多地用到这些语句,可能会形成多层的代码嵌套。代码的嵌套层数越大,代码的缩进层次就越深,这将会降低代码的可读性。本文要讲的“分解大括号”策略正是为了避免这种问题,它也可以使我们的代码变得更加整洁。 阅读全文
摘要:
代码是从命名开始的,我们给类、方法、变量和参数命名,我们也给解决方案、工程、目录命名。在编码时,除了应该遵守编程语言本身的命名规范外,我们应该提供好的命名。好的命名意味着良好的可读性,读你代码的人无需太多的注释,就能通过名称知道它是什么,它能做什么事儿,以及它应该怎么用。我们命名、命名,不断地命名。既然有这么多命名要做,我们不妨做好他。 阅读全文
摘要:
在程序中创建对象,并设置对象的属性,是我们长干的事儿。当创建对象需要大量的重复代码时,代码看起来就不那么优雅了。从类的职责角度出发,业务类既要实现一定的逻辑,还要负责对象的创建,业务类干的事儿也忒多了点。对象创建也是“一件事”,我们可以将“这件事”从业务代码中提取出来,让专门的类去做“这件事”,这就是本文要讲的主题——提取工厂类。 阅读全文
摘要:
试想这样一个场景,你提供了一些API给客户端调用,客户端传入了一些参数,然后根据这些参数执行了API逻辑,最终返回一个结果给客户端。
在这个场景中,有两个隐患,它们分别是:
客户端调用API时,传入的参数是否准确,参数是否满足API的执行前提
API逻辑执行完时,返回的结果是否准确,结果是否符合客户端的预期 阅读全文
摘要:
在一些较为复杂的业务中,客户端需要依据条件,执行相应的行为或算法。在实现这些业务时,我们可能会使用较多的分支语句(switch case或if else语句)。使用分支语句,意味着“变化”和“重复”,每个分支条件都代表一个变化,每个分支逻辑都是相似行为或算法的重复。今天我将介绍一种新的处理“变化”和“重复”的策略——“使用策略模式代替分支"。 阅读全文
摘要:
有时候你可能会在条件判断中,根据不同的对象类型(通常是基类的一系列子类,或接口的一系列实现),提供相应的逻辑和算法。
基于这种场景,我们可以考虑使用“多态”来代替冗长的条件判断,将if else(或switch)中的“变化点”封装到子类中。这样,就不需要使用if else(或switch)语句了,取而代之的是子类多态的实例,从而使得代码的可读性和可扩展性提高了——这就是本文要介绍的重构策略“使用多态代替条件判断”。 阅读全文
摘要:
我们有时候在应用程序中可能编写了一些“幽灵”类,“幽灵”类也叫中间类。这些中间类可能什么事儿都没做,而只是简单地调用了其他的组件。这些中间类没有发挥实际的作用,它们增加了应用程序的层级(layer),并且增加了应用程序的复杂性。这时,我们应将这样的中间类删除,甚至删除中间类所处的“中间层”——这就是本文要讲的重构策略“移除中间类”。 阅读全文