通过剔除上下文依赖减弱封装的耦合性

0

高内聚以内部功能的完备性衡量封装的度，低耦合以与外部的关联程度衡量封装的度。

看一个可以说是高内聚其实是高耦合的列子。

import { ValidateStatus } from 'antd/lib/form/FormItem';

export interface HeroState {
  name: string;
  status: ValidateStatus;
  help: string;
}

...

   this.onNameChange(e.target.value)}
    placeholder={'新增英雄名称'}
  />

...

  新增英雄

image.png

onAdd

  private onAdd = () => {
    const maxLength = 4;
    const { name } = this.state;
    let isPass = false,
      help = '',
      status: ValidateStatus = '';

    if (name.length > maxLength) {
      help = `长度不能大于${maxLength}`;
      status = 'error';
    } else if (name.trim().length === 0) {
      help = `请输入名字`;
      status = 'error';
    } else {
      isPass = true;
    }
    if (isPass) {
      //发起请求
    }

    this.setState({
      help: help,
      status: status,
    });
  };

效果:

1

在onAdd，狗蛋验证了英雄名字的合法性，这块逻辑完全可以独立出来，狗蛋本没有这么高的觉悟，奈何他发现还有修改的功能，也要验证名字...

于是乎

  private onAdd = () => {
    const { name } = this.state;
    const isPass = this.validateName(name);
    if (isPass) {
      //发起请求
    }
  };
  private validateName = (name: string): boolean => {
    const maxLength = 4;
    let isPass = false,
      help = '',
      status: ValidateStatus = '';

    if (name.length > maxLength) {
      help = `长度不能大于${maxLength}`;
      status = 'error';
    } else if (name.trim().length === 0) {
      help = `请输入名字`;
      status = 'error';
    } else {
      isPass = true;
    }
    this.setState({
      help: help,
      status: status,
    });
    return isPass;
  };

2

狗蛋愉快的下班回家了，然而第二天他绝望的发现，修改的时候还是无法复用，就是因为这段代码

    this.setState({
      help: help,
      status: status,
    });

修改和添加的的文本框不能共用help 和 status

最终修改如下:

interface IValidateInfo {
  isPass:boolean;
  status: ValidateStatus;
  help: string;
}
 private onAdd = () => {
    const { name } = this.state;
    const {isPass,status,help} = this.validateName(name);
    if (isPass) {
      //发起请求
    }
    this.setState({
      status,
      help
    })
  };
 
  private validateName = (name: string): IValidateInfo => {
    const maxLength = 4;

    let validateInfo: IValidateInfo = {
      isPass: true,
      help: '',
      status: '',
    };
    if (name.length > maxLength) {
      validateInfo = {
        ...validateInfo,
        help: `长度不能大于${maxLength}`,
        status: 'error',
      };
    } else if (name.trim().length === 0) {
      validateInfo = {
        ...validateInfo,
        help: `请输入名字`,
        status: 'error',
      };
    }

    return validateInfo;
  };

3

既然validateName 已经不依赖this了，它完全可以升级为静态方法或是移动到其他文件，一来可以据此划分代码，二来可以提升复用性。

上下文等同于闭包，依赖等同于访问外层作用域，最外层的闭包是window

绝不是有上下文依赖就都要剔除，若是变成了低内聚同样会给使用带来麻烦。

当产生纠结时，宁可低内聚也不要高耦合，把一把沙子放进一袋大米里容易，想要拿出来就难了。

因为高耦合有短视的利好性，可能在相当长的时间内也不会产生问题，毕竟业务有多样性，所以大多数情况下会写出高耦合的代码，尽管在理论层次上不够优雅，但对于实际来看不造成真实伤害
。

对于高内聚、低耦合的追求，无论是前期设计还是后期完善都没必要过度的投入时间，是否过度取决于你有多长时间，你的团队有多长时间

要优先整理非业务代码的逻辑，对于业务代码则从严重程度高的开始，比如不能满足当下需求、经常发生问题、迭代功能需要投入大量时间等。

随着代码和业务之间依赖的增加，高内聚、低耦合就和日益变化的需求息息相关，现在是2020年，如果一部手机里可以取出一把筷子，自然是高耦合，如果不能安装App，自然是低内聚，但以后可就说不准了。