https://github.com/YvetteLau/Blog

参考文章

一个封装组件提供 props 控制其行为而不是暴露其内部结构。

松耦合（易修改、易复用、易测试）

紧耦合

封装良好的组件隐藏其内部结构，并提供一组属性来控制其行为（其他组件不必知道组件的实现细节） 隐藏内部结构的组件彼此之间的依赖性较小，而降低依赖度会带来松耦合的好处

组件通信的方法：props

为了避免破坏封装，请注意通过 props 传递的内容。给子组件设置 props 的父组件不应该暴露其内部结构的任何细节。例如，使用 props 传输整个组件实例或 refs 都是一个不好的做法。访问全局变量同样也会对封装产生负面影响。

参考文献

当一个组件只有一个改变的原因时，它有一个单一的职责。

为什么只有一个理由可以改变很重要？因为这样组件的修改隔离并且受控。单一职责原则制了组件的大小，使其集中在一件事情上。集中在一件事情上的组件便于编码、修改、重用和测试。

下面我们来举几个例子

发生变化的原因是：

修改服务器 URL 修改响应格式 要使用其他 HTTP 请求库 或仅与获取逻辑相关的任何修改。

发生变化的原因是：

你需要限制渲染行组件的数量（例如，最多显示 25 行） 当没有要显示的项目时，要求显示提示信息“列表为空” 或仅与数组到行组件的映射相关的任何修改。

例如， 同时有两个职责，绘制图表，并处理为该图表提供数据的表单。 就会有两个更改原因：绘制图表和处理表单。 当你更改表单字段（例如，将 修改为 时，你无意中中断图表的渲染。此外，图表实现是不可重用的，因为它与表单细节耦合在一起。

解决多重责任问题需要将 分割为两个组件： 和。每个组件只有一个职责：绘制图表或处理表单。组件之间的通信是通过 props 实现。

设想一个组件向一个专门的服务器发出 HTTP 请求，以获取当前天气。成功获取数据时，该组件使用响应来展示天气信息

这个天气组件有两个改变原因：

componentDidMount() 中的 fetch 逻辑：服务器 URL 或响应格式可能会改变。 render() 中的天气展示：组件显示天气的方式可以多次更改。

可分为两个组件，一个组件负责获取天气、提取响应数据并将其保存到 state 中。改变原因：获取数据逻辑改变 另一个组件负责显示天气，改变原因只可能是视觉显示改变

高阶组件是一个接受一个组件并返回一个新组件的函数。

高阶组件常见用法：为封装的组件增加新属性或修改现有属性值（这种技术为属性代理）

一个组合式组件是由更小的特定组件组合而成的。

那么组合与单一责任以及封装有什么联系呢？ 单一责任原则描述了如何将需求拆分为组件，封装描述了如何组织这些组件，组合描述了如何将整个系统粘合在一起。

好处：通过子组件分别实现单一职责的方式，是组件也符合单一职责原则

优点：

可重用 组合有可重用的优点，使用组合的组件可以重用公共逻辑 可重用的组件符合不重复自己(Don’t repeat yourself)的原则。这种做法可以节省你的精力和时间，并且在后期，有利于代码维护。

灵活 在 react 中，一个组合式的组件通过给子组件传递 props 的方式，来控制其子组件。这就带来了灵活性的好处

高效 用户界面可组合的层次结构，因此，组件的组合是一种构建用户界面的有效的方式。

经过测试的组件验证了其在给定输入的情况下，输出是否符合预期。（可测试意味着良好的设计） 可测试组件易于测试。

如果你计划手动验证每个组件的修改，那么迟早，你会跳过这个繁琐的环节，进而导致你的组件迟早会出现缺陷。

这就是为什么自动化组件验证很重要：进行单元测试。单元测试确保每次进行修改时，组件都能正常工作。

单元测试不仅涉及早期错误检测。 另一个重要方面是能够验证组件架构是否合理。

一个不可测试或难以测试的组件很可能设计得很糟糕。

当组件的架构设计很脆弱时，就会变得难以测试，而当组件难以测试的时候，你大概念会跳过编写单元测试的过程，最终的结果就是：组件未测试。

开发人员大部分时间都在阅读和理解代码，而不是实际编写代码。我们花 75％的时间理解代码，花 20％的时间修改现有代码，只有 5％编写新的代码。

在可读性方面花费的额外时间可以减少未来队友和自己的理解时间。当应用程序增长时，命名实践变得很重要，因为理解工作随着代码量的增加而增加。