keepfool

摘要： 异常处理的关键在于何时处理异常以及如何使用异常，有些开发者会觉得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），并且增加了应用程序的复杂性。这时，我们应将这样的中间类删除，甚至删除中间类所处的“中间层”——这就是本文要讲的重构策略“移除中间类”。 阅读全文

摘要： 为了方便大家阅读这个系列的文章，我弄了个目录汇总。主要包含4个部分：1. 方法、字段重构 2.类、接口重构 3.设计模式重构 4.一般性重构 阅读全文

摘要： 有些开发者为了贪图简便，看到一个现成的类，也不管这个类是做什么的，需要追加功能时，就向这个类里面添加功能代码。久而久之，使得一些类变成了“上帝类”。什么是“上帝类”？上帝类也叫万能类，意指做了太多“事情”的类。在开发过程中，我们应该保持一个良好的习惯，在类中追加功能时，一定要事先确认类的职责，并控制好类的粒度，这有益于代码的可读性、扩展性、维护和修改。 阅读全文