хитросплетениях Ваших довольно сложных и многочисленных классов.
о каких конкретно классах идёт речь?
В Д2 одна коротенькая функция (в десяткок простых строк) с одним циклом, плюс 3 ее вызова. А в Д3 только первый фрагмент содержит три функции со сложным содержимым каждая. По моему, Д3 не просто сложнее Д2, а сложнее на порядок.
Давайте попробуем разобраться. Я так понимаю речь идет о классе FrontExtender. Там свойство $deliveryPrices и метод getDeliveryPrice() вообще 100% аналоги доработки для второго окая.
Метод getCartDeliveriesList() он внутри себя создает экземпляр класса ServiceLocator() (что очевидно), также я думаю не нужно пояснять что такое локатор служб. затем мы из локатора достаём сервисы, которые нам нужны
Код: Выделить всё
/** @var FrontTranslations $frontTranslations */
$frontTranslations = $SL->getService(FrontTranslations::class);
/** @var EntityFactory $entityFactory */
$entityFactory = $SL->getService(EntityFactory::class);
/** @var Money $money */
$money = $SL->getService(Money::class);
По сути ранее это же делалось через $this->front_translation->getTranslation(). Но как минимум такой код морально устарел (не буду вдаваться в детали чего отказались от класса Okay и перешли на DI контейнер).
В переменной $entityFactory лежит экземпляр класса фабрики сущностей, далее мы получаем экземпляр класса Okay\Entities\CurrenciesEntity и далее уже вызываем метод get() этого экземпляра. Ранее это было как $this->currencies->get_currency((int)$_SESSION['currency_id']);
сейчас
Код: Выделить всё
$currenciesEntity = $entityFactory->get(CurrenciesEntity::class);
$currency = $currenciesEntity->get((int)$_SESSION['currency_id']);
на целую строчку сложнее. Если очень принципиально, напишите
Код: Выделить всё
$currency = $entityFactory->get(CurrenciesEntity::class)->get((int)$_SESSION['currency_id']);
то же самое, но не так читаемо.
Классы Money и CurrenciesEntity нужны для того, чтобы в $delivery->delivery_price_text можно было добавить стоимость доставки, которая выводится здесь
http://prntscr.com/pqiq5x, связанно это уже с переработкой самой корзины в третьем окае. Далее мы в форыче модифицируем стоимость доставки и отдаём её. Далее вопрос, когда вызывается метод getCartDeliveriesList()? в классе Init прописана регистрация цепочного вызова метода FrontExtender::getCartDeliveriesList() после метода DeliveriesHelper::getCartDeliveriesList(). Собственно метод DeliveriesHelper::getCartDeliveriesList() возвращает массив доставок, а в метод DeliveriesHelper::getCartDeliveriesList() они попадают на вход как аргумент, и метод их модифицирует описанным выше образом и возвращает. Таким образом модули в принципе могут работать с системой.
zyxer писал(а):
его будет гораздо легче поддерживать чем аналогичный модуль для второго окая.
Вы уже несколько раз это повторяли, и каждый раз голословно.
Чем это легче, ни разу не дали даже общих пояснений, не говоря уж о конкретных.
Буду выражать только своё мнение )) легче это тем, что код всего модуля собран в одном месте, мне не нужно править его по всей системе, я точно знаю что нигде не забуду отметить код комментарием (как это делалось для второго окая), потому как мой код не находится в ядре. Да, эта доработка попала в те места, которые приктически не менялись с 2.0.0, но допустим бы мы вставляли свой код между строк, которые правились в окае, вам нужно обязательно обновлять свой модуль, т.к. пользователи не смогут его ставить (как я уже говорил, все ориентируются по соседним строкам). В случае с 3, такой проблемы быть не должно.
Но чаще встречаются другие ситуации, где слишком много взаимосвязано, чтобы можно было легко разложить на независимые части.
Это прям тезис из книг, где говорится что если у вас код слишком связан, что-то идет не так )) Больше даже комментировать не хочу
И наконец, возьмем для примера Вашу разработку Д3. Там есть
use Okay\Modules\OkayCMS\NovaposhtaCost\Extenders\FrontExtender;
Мелкая ошибочка, особо не проявится, но все же ошибка.
да, писал на коленке в обед, и не обратил внимания )) Спасибо за замечание. Тот файл на самом деле вообще не нужен.
Так же вы как разработчик модуля вполне можете покрывать его автотестами, чего ранее нельзя было сделать при всём желании.
Еще, я чтобы не усложнять код для 3 сделал методы getCartDeliveriesList и getDeliveryPrice в одном классе, но они должны быть в разных классах. Один это часть приложения, второй это часть бизнес-логики.
[quote]хитросплетениях Ваших довольно сложных и многочисленных классов.[/quote] о каких конкретно классах идёт речь?
[quote]В Д2 одна коротенькая функция (в десяткок простых строк) с одним циклом, плюс 3 ее вызова. А в Д3 только первый фрагмент содержит три функции со сложным содержимым каждая. По моему, Д3 не просто сложнее Д2, а сложнее на порядок. [/quote]
Давайте попробуем разобраться. Я так понимаю речь идет о классе FrontExtender. Там свойство $deliveryPrices и метод getDeliveryPrice() вообще 100% аналоги доработки для второго окая.
Метод getCartDeliveriesList() он внутри себя создает экземпляр класса ServiceLocator() (что очевидно), также я думаю не нужно пояснять что такое локатор служб. затем мы из локатора достаём сервисы, которые нам нужны
[code]/** @var FrontTranslations $frontTranslations */
$frontTranslations = $SL->getService(FrontTranslations::class);
/** @var EntityFactory $entityFactory */
$entityFactory = $SL->getService(EntityFactory::class);
/** @var Money $money */
$money = $SL->getService(Money::class);
[/code]
По сути ранее это же делалось через $this->front_translation->getTranslation(). Но как минимум такой код морально устарел (не буду вдаваться в детали чего отказались от класса Okay и перешли на DI контейнер).
В переменной $entityFactory лежит экземпляр класса фабрики сущностей, далее мы получаем экземпляр класса Okay\Entities\CurrenciesEntity и далее уже вызываем метод get() этого экземпляра. Ранее это было как $this->currencies->get_currency((int)$_SESSION['currency_id']);
сейчас [code]
$currenciesEntity = $entityFactory->get(CurrenciesEntity::class);
$currency = $currenciesEntity->get((int)$_SESSION['currency_id']);[/code]
на целую строчку сложнее. Если очень принципиально, напишите [code]$currency = $entityFactory->get(CurrenciesEntity::class)->get((int)$_SESSION['currency_id']);[/code] то же самое, но не так читаемо.
Классы Money и CurrenciesEntity нужны для того, чтобы в $delivery->delivery_price_text можно было добавить стоимость доставки, которая выводится здесь http://prntscr.com/pqiq5x, связанно это уже с переработкой самой корзины в третьем окае. Далее мы в форыче модифицируем стоимость доставки и отдаём её. Далее вопрос, когда вызывается метод getCartDeliveriesList()? в классе Init прописана регистрация цепочного вызова метода FrontExtender::getCartDeliveriesList() после метода DeliveriesHelper::getCartDeliveriesList(). Собственно метод DeliveriesHelper::getCartDeliveriesList() возвращает массив доставок, а в метод DeliveriesHelper::getCartDeliveriesList() они попадают на вход как аргумент, и метод их модифицирует описанным выше образом и возвращает. Таким образом модули в принципе могут работать с системой.
[quote]zyxer писал(а):
его будет гораздо легче поддерживать чем аналогичный модуль для второго окая.
Вы уже несколько раз это повторяли, и каждый раз голословно.
Чем это легче, ни разу не дали даже общих пояснений, не говоря уж о конкретных.[/quote]
Буду выражать только своё мнение )) легче это тем, что код всего модуля собран в одном месте, мне не нужно править его по всей системе, я точно знаю что нигде не забуду отметить код комментарием (как это делалось для второго окая), потому как мой код не находится в ядре. Да, эта доработка попала в те места, которые приктически не менялись с 2.0.0, но допустим бы мы вставляли свой код между строк, которые правились в окае, вам нужно обязательно обновлять свой модуль, т.к. пользователи не смогут его ставить (как я уже говорил, все ориентируются по соседним строкам). В случае с 3, такой проблемы быть не должно.
[quote]Но чаще встречаются другие ситуации, где слишком много взаимосвязано, чтобы можно было легко разложить на независимые части.[/quote] Это прям тезис из книг, где говорится что если у вас код слишком связан, что-то идет не так )) Больше даже комментировать не хочу
[quote]И наконец, возьмем для примера Вашу разработку Д3. Там есть
use Okay\Modules\OkayCMS\NovaposhtaCost\Extenders\FrontExtender;
Мелкая ошибочка, особо не проявится, но все же ошибка.[/quote] да, писал на коленке в обед, и не обратил внимания )) Спасибо за замечание. Тот файл на самом деле вообще не нужен.
Так же вы как разработчик модуля вполне можете покрывать его автотестами, чего ранее нельзя было сделать при всём желании.
Еще, я чтобы не усложнять код для 3 сделал методы getCartDeliveriesList и getDeliveryPrice в одном классе, но они должны быть в разных классах. Один это часть приложения, второй это часть бизнес-логики.
Всё сказанное мной, является лично моим мнением, и не является официальной позицией OkayCMS