ivanov77
Новичок
Приветствую.
Есть обычный хэлпер, просто как набор статических методов. Ну например как такие в yii2 и уже что касается не инфраструктуры, а функционала самого приложения, типа:
Насколько я понял спецы по ООП очень сильно недолюбливают такие хэлперы по причине:
- жесткой завязанности на нем (В yii вон им пришлось по 2 класса делать, чтобы подменить через костыли в случае чего)
- по мере роста кол-ва методов эти хэлперы надо дробить, и когда не совсем точно понятно куда новый метод добавлять, добавляют наугад, а потом естественно не могут найти.
Какой в этом плане кошерный подход?, для вот этих всех служебных, вспомогательных вещей, что никак не уместилось в объекты предметной области, вещи которые могут понадобиться много где, и в UI и в Сервисах приложения(use case-ах).
Так пойдет?:
- Назвать такие классы Сервисами
- Создавать такие классы без состояния, с набором нестатических методов, сгруппированных по смыслу.
- Вопросы расширения функционала этих классов решать посредством https://refactoring.guru/ru/introduce-local-extension . Это заодно согласуется и с OCP.
- инжектить их через DI уже там где нужны.
- Не создавать интерфейсы для каждого из них, а инжектить как класс. Завязки жесткой не будет. Всегда можно будет подменить на наследника или сдекорированный, фреймворки такое позволяют.
Есть обычный хэлпер, просто как набор статических методов. Ну например как такие в yii2 и уже что касается не инфраструктуры, а функционала самого приложения, типа:
Код:
class CommonHelper
{
//////////////////////////////
////////// Urls
//////////////////////////////
public static function getUrlToPageById($pid, $params = [], $scheme = false)
{
if ($arr = Yii::$app->urlManager->getPageInfoByPid($pid)) {
$params = array_merge($params, ['lang' => $arr['lang'], 'cross' => 'front']);
return self::urlTo('/' . $arr['source'], $params, $scheme);
}
return null;
}
//...
//////////////////////////////
////////// Files
//////////////////////////////
public static function getImageInfoFromMiniPath($miniPath, $imageTypes)
{
$res = [];
$miniPath = str_replace('../', '', $miniPath);
$miniPath = ltrim($miniPath, '/');
$parts = explode('/', $miniPath);
if (count($parts) < 2) {
return null;
}
$name = array_pop($parts);
$res['filename'] = $name;
$x2 = explode('.', $name);
$res['fileext'] = array_pop($x2);
// Pattern will be like this: '/.+\.((jpg)|(jpeg)|(png)|(bmp)|(gif))$/'
$pattern = '/.+\.((' . implode(')|(', $imageTypes) . '))$/';
if (!preg_match($pattern, $name)) {
return null;
}
$res['miniformat'] = array_pop($parts);
$parts[] = $name;
$res['imagepath'] = implode('/', $parts);
return $res;
}
//////////////////////////////
////////// Tokens
//////////////////////////////
//...
}- жесткой завязанности на нем (В yii вон им пришлось по 2 класса делать, чтобы подменить через костыли в случае чего)
- по мере роста кол-ва методов эти хэлперы надо дробить, и когда не совсем точно понятно куда новый метод добавлять, добавляют наугад, а потом естественно не могут найти.
Какой в этом плане кошерный подход?, для вот этих всех служебных, вспомогательных вещей, что никак не уместилось в объекты предметной области, вещи которые могут понадобиться много где, и в UI и в Сервисах приложения(use case-ах).
Так пойдет?:
- Назвать такие классы Сервисами
- Создавать такие классы без состояния, с набором нестатических методов, сгруппированных по смыслу.
- Вопросы расширения функционала этих классов решать посредством https://refactoring.guru/ru/introduce-local-extension . Это заодно согласуется и с OCP.
- инжектить их через DI уже там где нужны.
- Не создавать интерфейсы для каждого из них, а инжектить как класс. Завязки жесткой не будет. Всегда можно будет подменить на наследника или сдекорированный, фреймворки такое позволяют.
