Шаблоны проектирования: следует ли перенести повторяющиеся вызовы функций в разные модули в свою собственную «абстракцию»? - PullRequest
Новая
       55

Шаблоны проектирования: следует ли перенести повторяющиеся вызовы функций в разные модули в свою собственную «абстракцию»?

0 голосов
/ 11 октября 2019

Как разработчик 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. Как вы можете видеть, он вызывает различные функции при инициализации, когда приложение загружается.

Допустим, я однажды смогу повторить этот код в другой части приложения (некоторые автоматическиавторизоваться). «Привычно» ставить такой код в своем классе? Я имею в виду, что это полностью нарушит принцип Единой ответственности , так как этот класс / модуль будет тесно связан со многими другими классами и обязанностями.

Это всего лишь один пример (возможно, нелучший), но эта дилемма возникает часто. Как опытные разработчики подходят к этой проблеме?

1 Ответ

1 голос
/ 11 октября 2019

Аббревиатура СУХОЙ - не повторяйся - скажи все. А извлечение кода полностью соответствует принципу единой ответственности, поскольку новый класс будет отвечать только за одну вещь, процесс входа в систему, и будет иметь только одну причину для изменения, а именно, если процесс входа в систему изменится. Все остальные объекты, использующие компонент входа в систему, не заботятся (если API не изменяется), что вам и нужно. Соединение создает проблему, если вам нужно изменить API вашего компонента, поэтому всегда старайтесь создавать понятные и стабильные API.

...