重构16-Encapsulate Conditional(封装条件)

当代码中充斥着若干条件判断时,代码的真正意图会迷失于这些条件判断之中。这时我喜欢将条件判断提取到一个易于读取的属性或方法(如果有参数)中。重构之前的代码如下:

public class RemoteControl {    private String[] Functions;//getter setterprivate String Name;//getter setterprivate int CreatedYear;//getter setter

public String PerformCoolFunction(String buttonPressed) {        // Determine if we are controlling some extra function        // that requires special conditionsif (Functions.length > 1 && Name == "RCA" && CreatedYear > new Date().getYear() - 2) {            return "doSomething";}        return null;}}

重构之后,代码的可读性更强,意图更明显:

public class RemoteControl {    private String[] Functions;//getter setterprivate String Name;//getter setterprivate int CreatedYear;//getter setterprivate Boolean HasExtraFunctions;

    public Boolean getHasExtraFunctions() {        return Functions.length > 1 && Name == "RCA" && CreatedYear > new Date().getYear() - 2;}    public String PerformCoolFunction(String buttonPressed) {        // Determine if we are controlling some extra function        // that requires special conditionsif (HasExtraFunctions) {            return "doSomething";}        return null;}}

来自为知笔记(Wiz)

时间: 08-18

重构16-Encapsulate Conditional(封装条件)的相关文章

【Java重构系列】重构31式之封装集合

2009年,Sean Chambers在其博客中发表了31 Days of Refactoring: Useful refactoring techniques you have to know系列文章,每天发布一篇,介绍一种重构手段,连续发文31篇,故得名“重构三十一天:你应该掌握的重构手段”.此外,Sean Chambers还将这31篇文章[即31种重构手段]整理成一本电子书, 以下是博客原文链接和电子书下载地址: 博客原文:http://lostechies.com/seanchamber

小酌重构系列[23]——封装条件

概述 当条件判断语句较为复杂时(有多个不同的检查项),就像下面这幅图所表示的,会使得代码的可读性会大打折扣,也难以清晰地传达判断意图. 再者,当判断逻辑变更时,我们不得不去修改if语句里面的判断代码.如果判断写得有问题,则会影响方法的正确性,也会给该方法的单元测试带来一些障碍. 我们可以根据检查项是否需要参数来封装条件,如果检查项不需要参数,则可以将其提取为属性:如果需要参数,则将其提取为方法.本文要讲的重构策略"封装条件"是基于"提取方法"这个重构策略的. 示例

小酌重构系列[23]——封装条件

当条件判断语句较为复杂时(有多个不同的检查项),就像下面这幅图所表示的,会使得代码的可读性会大打折扣,也难以清晰地传达判断意图. 再者,当判断逻辑变更时,我们不得不去修改if语句里面的判断代码.如果判断写得有问题,则会影响方法的正确性,也会给该方法的单元测试带来一些障碍. 我们可以根据检查项是否需要参数来封装条件,如果检查项不需要参数,则可以将其提取为属性:如果需要参数,则将其提取为方法.本文要讲的重构策略“封装条件”是基于“提取方法”这个重构策略的. 示例 重构前 这个示例中,PerformC

封装条件

概念:本文中的"封装条件"是指条件关系比较复杂时,代码的可读性会比较差,所以这时我们应当根据条件表达式是否需要参数将条件表达式提取成可读性更好的属性或者方法,如果条件表达式不需要参数则可以提取成属性,如果条件表达式需要参数则可以提取成方法. 正文:如下代码所示,PerformCoolFunction里面的if条件判断比较复杂,看起来有点杂乱,所以就把它提出来. using System; namespace LosTechies.DaysOfRefactoring.Encapsulat

重构第一天:封装集合

在一些情况下,在一个类中选择不去暴露整个集合给调用者是非常有必要的.比如当我们给一个集合添加/删除item时,我们需要添加一些额外的逻辑.因为这个原因,一个非常好的办法就是让暴露出来的collecction只能被迭代而不能被修改.让我们看下面的例子. public class Order { private List<OrderLine> _orderLines; public IEnumerable<OrderLine> OrderLines { get { return _or

封装条件(Encapsulate Conditional)

封装就是将相关的方法或者属性抽象成为一个对象. 封装的意义: 对外隐藏内部实现,接口不变,内部实现自由修改. 只返回需要的数据和方法. 提供一种方式防止数据被修改. 更好的代码复用. 当代码中包含许多条件判断,为了改善代码的可读性和可维护性,我们可以将条件封装. 有两种封装方式: 一.无参数的条件判断,封装为属性 重构前代码 public class RemoteControl { private string[] Functions { get; set; } private string N

重构第18天 用条件语句来代替异常(Replace exception with conditional)

理解:本文中的“使用条件判断代替异常”是指把没有必要使用异常做判断的条件尽量改为条件判断. 详解: 重构前代码: 1 public class Microwave 2 { 3 private IMicrowaveMotor Motor { get; set; } 4 5 public bool Start(object food) 6 { 7 bool foodCooked = false; 8 try 9 { 10 Motor.Cook(food); 11 foodCooked = true;

重构18-Replace exception with conditional(条件替代异常)

重构没有什么出处,是我平时经常使用而总结出来的.欢迎您发表任何改进意见或建议.我相信一定还有其他比较好的重构可以解决类似的问题. 我曾无数次面对的一个代码坏味道就是,使用异常来控制程序流程.您可能会看到类似的代码: public class Microwave { private MicrowaveMotor Motor;//getter setter public Boolean start(Object food) { Boolean foodCooked = false; try { Mo

windows环境下封装条件wait和signal

linux 环境有提供好的pthread_cond_wait() 和 phread_signal().pthread_broadcast() windows需要自己封装,利用semophore控制线程等待和释放,先简单谈一下设计好后api该 如何使用. 假设我们封装好条件变量等待函数名字叫做wait(Mutex& mutex),Mutex是之前我们封装的 条件变量,文章最下边会给出这些文件的下载地址,在这里读者当做linux 的mutex即可.我们 封装的释放函数为signal(),广播函数为b