Именование в программировании, классов, сервисов

Qzed

Новичок
Решил вот обсудить, попав на удивительный как по мне вариант (код ниже), ну я бы не дошел до такого.
Все больше волнует именно тема именования, распределения кода по классам,
ради следования SOLID и в улучшению своего кода.
Часто поражаюсь откуда берут такие как Applicator Matcher Resolver Provider Manager и Processor etc

И вот пример из Sylius
PHP:
final class CustomerUniqueAddressAdder implements CustomerAddressAdderInterface
{
    /** @var AddressComparatorInterface */
    private $addressComparator;

    public function __construct(AddressComparatorInterface $addressComparator)
    {
        $this->addressComparator = $addressComparator;
    }

    /**
     * {@inheritdoc}
     */
    public function add(CustomerInterface $customer, AddressInterface $address): void
    {
        foreach ($customer->getAddresses() as $customerAddress) {
            if ($this->addressComparator->equal($customerAddress, $address)) {
                return;
            }
        }

        $customer->addAddress($address);
    }
}
и CustomerOrderAddressesSaver там же, который будет адрес с заказа, сохранять пользователю в профиль.

Да есть разные книги по программированию, но не по именованию.
Т.е. видя пример понимаю что можно и так писать НечтоAdder НечтоSaver

Например так будет правильно: RewardPointAdder который будет Customer'у начислять бонусные баллы ?


Также и с Applicator Matcher Resolver Provider Manager и Processor etc
Хорошо бы иметь больше вариантов именования сразу.
Само собой что то есть в книгах, но больше только в проектах где реально что то делается.
 
Последнее редактирование:

AnrDaemon

Продвинутый новичок
По-моему, кому-то надо PoEAA почитать. Предположительно, вам обоим.
 

Qzed

Новичок
По-моему, кому-то надо PoEAA почитать. Предположительно, вам обоим.
SkillAdder вот из всей книги 1 один пример так именуемого класса. И я писал про книги само собой, вопрос больше о чем то вроде справочника, вариантов. Ну паттерны ещё есть, но и там не все
 

fixxxer

К.О.
Партнер клуба
Именовать надо так, чтобы было понятно. Тут куда лучше руководствоваться понятием Ubiquitous Language из DDD.

Если возникают проблемы с именованием, значит, сначала надо провериться на коронавирус и нарушение SRP.

А этот Adder... на первый взгляд, выглядит как Command, но если присмотреться, это какая-то хрень. Я, конечно, не знаю специфики этой кодобазы, но из общих соображений разумно было бы сделать CustomerAddress обычным Value Object, реализующим equalsTo(CustomerAddress $other): bool, а логику про дублирование разместить несосредственно в Customer->addAddress(). Полагаю, что автор этого кода страдает анемизмом моделей и джавой головного мозга. Допускаю также, что подобная странная архитектура сделана с целью расширяемости домена плагинами, но подобные системы - это отдельная область нечеловеческих извращений, это не стоит брать за пример, если не стоит задача сделать что-то похожее.
 
Последнее редактирование:

Qzed

Новичок
То Sylius eCommerce platform on top of Symfony. В symfony все так.

А в сторону команд думал, тут проще в плане именования, сделать то се и ясно. Пишу и такой код, команды вместо сервисов. Пробую.

Но мало реальных проектов отрытых с таким подходом. Ubiquitous читал да хорошая идея.


Но речь о сервисах именно, так как тут кроме имени надо суффикс ещё
Что то решает Resolver
Что то применяет DiscountApplicator
Что то проверяет DiscountMatcher
Checker etc этож надо фантазию иметь.
Захотели вот уже и Adder какой то.

Ладно вопрос закрыл, разве что по CQRS есть что добавить ..
 
Последнее редактирование:

fixxxer

К.О.
Партнер клуба
Если без суффиксов получается выразить суть, соответствующую той самой single responsibility - так ваще отлично.
 

fixxxer

К.О.
Партнер клуба
А, ну понятно, специфика продукта. Когда предметной областью является по сути расширение предметной области, всегда жопа и пляски
Симфони сам по себе ничего такого не навязывает. Предметку вообше лучше писать на plain PHP objects.
 

Yoskaldyr

.
Партнер клуба
@Qzed Если используешь готовый продукт, не важно на чем - просто смирись. Везде треш, не важно на чем на симфони
или на чем-то другом

Я подобную тему еще давно поднимал
 

Qzed

Новичок
@Yoskaldyr да тему читал твою, до того как спрашивать. И нет дело не в том с чем работаешь, а именно в том что свой код пишешь, и там задумываешься.

Когда видишь как пишут классами с суфиксами, то без них напр Promocodes и все супер класс, то уже командами как CQRS, вот больше сюда смотрю уже, лучше чем выдумывать именование сервисов с единой ответственностью.
 

Yoskaldyr

.
Партнер клуба
В первом посте был пример из коробочного продукта и это реально треш, как раз именно то о чем я писал в своей теме
Проблема не только в правильном именовании класса, а и в том что очень часто приходится писать почти весь неймспейс в имя класса, т.е. фактически дублировать его. И если иногда это более менее терпимо, то иногда будет треш из первого поста
 
  • Like
Реакции: Qzed

Yoskaldyr

.
Партнер клуба
@Qzed И учитывая специфику PSR4, то очень часто именование классов - это следствие группировки классов приложения. Так что и вопрос будет как сгруппировать код приложения, но коробочные продукты диктуют свою структуру и свои правила именования, поэтому только смириться.

Если же вопрос чисто теоретический, то не стоит приводить примеры коробочных продуктов - они лютый треш (доказано не раз срачами здесь на форуме :)))
 
  • Like
Реакции: Qzed
Сверху