设计模式：对不同模块的重复函数调用是否应该移到它们自己的“抽象”中？答案

【问题标题】：Design patterns: Should repetitive function calls, to different modules, be moved to their own "abstraction"?设计模式：对不同模块的重复函数调用是否应该移到它们自己的“抽象”中？
【发布时间】：2019-10-11 16:04:46
【问题描述】：

作为一名 JS 开发人员，我经常发现自己在纠结于是否应该将某些“程序”移到它们自己的层。例如：

const localStorageUser = jwtService.userExistsInStorage();//Returns a user object if available
if (localStorageUser) {//If so, "login" from it
    // debugger;
    store.dispatch(userActions.setUserData(localStorageUser))//Set the user object in the Redux store.
    AjaxService.setHeader('token', localStorageUser.data.token);//Set the token header for every ajax request.

    if (localStorageUser.data.shortcuts) {
        store.dispatch(navigationActions.setNavigation(localStorageUser.data.shortcuts));
    } else {
        store.dispatch(navigationActions.resetNavigation());
    }
}

这是来自 React 应用中顶级文件的一些代码。如您所见，它会在应用加载时在初始化时调用各种函数。

假设有一天我可能会发现自己在应用程序的不同部分重复此代码（一些自动重新登录）。将此类代码放在自己的类中是否“习惯”？我的意思是，这样做完全违反了单一职责原则，因为这个类/模块将与许多其他类和职责高度耦合。

这只是一个例子（也许不是最好的例子），但这种困境经常出现。有经验的开发人员如何处理这个问题？

【问题讨论】：

标签： javascript reactjs design-patterns abstraction single-responsibility-principle

【解决方案1】：

首字母缩略词 DRY - 不要重复自己 - 仅此而已。并且提取适合的代码完全符合单一职责原则，因为新类将只负责一件事，即登录过程，并且只有一个改变的原因，即如果登录过程发生变化。所有其他使用登录组件的对象都不会关心（如果 API 没有更改），这正是您想要的。如果您必须更改组件的 API，耦合会产生问题，因此请始终尝试创建清晰且稳定的 API。

【讨论】：