все тки в примерах по срп почему то не говорят никогда про бизнес и задачи которые он ставит просто какой то класс Car и автор решает примерами srp

короч есть 2 ооп - один который пошел из симулы и C++ и православный смолтоковский. Ты сейчас говоришь о симуле и плюсах (и ни тот ни другой не задумывались как ООП языки)

Я учил С++ прости

чтобы писать на пхп?

Я учил С++ прости

ну значит ты потерян для общества

это фиаско, братан..

Может быть

но если интересно как-нибудь обсудить вопросы тру ооп - милости просим) это всегда интересно)

Объектно-ориентированный подход: Когда кода становится много, его нужно как-то разбить по процедурам. Когда процедур становится много, то их нужно как-то сгруппировать по обязанностям и разнести по модулям. Если несколько процедур и функций как-то связаны работой с одними и теми же данными, то их удобнее вместе с этими данными сгруппировать в объект. Но если просто возьмёте груду кода и просто перенесёте процедуры в классы, как я говорил на итенсиве, то не станете сразу объектно-ориентированным программистом. Это другой подход к компоновке кода. Целый отдельный образ жизни и мыслей. Настоящее ООП нацелено на разделение обязанностей и сокрытие информации.

чтобы писать на пхп?

А вы из тех 'PHP шлак!, php скоро умрет!'

А вы из тех 'PHP шлак!, php скоро умрет!'

нет, скорее из тех кто грустно пишет на php вкусив нормальных языков(

Объектно-ориентированный подход: Когда кода становится много, его нужно как-то разбить по процедурам. Когда процедур становится много, то их нужно как-то сгруппировать по обязанностям и разнести по модулям. Если несколько процедур и функций как-то связаны работой с одними и теми же данными, то их удобнее вместе с этими данными сгруппировать в объект. Но если просто возьмёте груду кода и просто перенесёте процедуры в классы, как я говорил на итенсиве, то не станете сразу объектно-ориентированным программистом. Это другой подход к компоновке кода. Целый отдельный образ жизни и мыслей. Настоящее ООП нацелено на разделение обязанностей и сокрытие информации.

Все верно 4 принципа полиморфизм, наследовани, инкапсуляция ну и абстракция

А вы из тех 'PHP шлак!, php скоро умрет!'

поддерживаем комьюнити, несем пхп в массы, контрибьютим в опенсорс, ну а так да, конечно же мы убиваем пхп

Все верно 4 принципа полиморфизм, наследовани, инкапсуляция ну и абстракция

почему наследование это принцип?

нет, скорее из тех кто грустно пишет на php вкусив нормальных языков(

Зачем делать то что не нравится?

Зачем делать то что не нравится?

потому что не всегда надо делать только то что нравится)

4 краеугольных камня, хорошо

Зачем делать то что не нравится?

я где-то сказал что мне не нравится?

потому что не всегда надо делать только то что нравится)

Лучшая работа это хорошо оплачиваемое хобби

4 краеугольных камня, хорошо

что если я скажу что наследование не нужно (ибо все о чем наследование покрывается полиморфизмом) а абстракция и инкапсуляция можно свести к information hiding?

Лучшая работа это хорошо оплачиваемое хобби

ну а еще есть "плевать на чем писать, лишь бы задачи интеесные". Но от этого тоска по php не уходит

ну и меня в php больше не язык а пользователи языка напрягают)

потому и сижу тут в чатике - глядишь кто-нибудь задумается о том что вся эта фигня с "4-мя краеугольными камнями" это бред наркомана и если все так почему никто не понимает эти камни

Я вот го собрался разбирать интересно мне

Ну симфони с пыхом пока кормит

Я вот го собрался разбирать интересно мне

простой язык

как же ты без наследования там жить будешь?

структурный тайпинг и полиморфизм)

Я не крещеный справляюсь

Я не крещеный справляюсь

ну ты просто задумайся и дай определение принципу наследования (и чем это отличается от полиморфизма_

ну и еше - все это названное было ДО ооп

сильно так до

Так все же что с transchoice есть кто то, кто тупо работает не прибегая к высоким материям мира ООП?

с i18n наверное тебе тут не помогут

ну я пока даже вопроса конкретного не вижу

пока могу только в доки послать

Так все же что с transchoice есть кто то, кто тупо работает не прибегая к высоким материям мира ООП?

но это же ты начал задвигать про солиды, кисы и прочее) и при этом выходит так же как у тех кто не загоняется)

может быть чуточку лучше

Жаль, спасибо. Интересная дискуссия, я поддерживаю использую и пропагандирую саморазвитие, иногда тоже страдаю задродством, в хорошем смысле слова. Но обычно на свой проект есть 2 - 3 часа на выходных, когда ребенок спит поэтому, тратить их на холивары о сферичечких конях нет времени да и желания. Главное во всех этих подходах понимать и оценивать, все риски и усложнения которые вызовут использование той или иной философии. Тупое следование SOLID приведет к краху проекта раньше чем проект может себе позволить. Поэтому очень часто проекты написаные на коленке работают лучше и решают свою задачу чем те которые потерялись в абстракциях. Мы говорим о высоких материях и они очень редко пересекаются с бизнессом. И потратить на разработку 100 лишних часов сегодня и избежать потери 1000 часов в будущем эторазные временные рамки для заказчика. И он выберет в 99% последнее. Ведь если разобраться то скрам тоже шлак так как приводит к быстрым релизам которые только увеличивают технический долг. Резюмируя все выше изложенное, во всем нужно разбираться, тупое следование чьим либо принципам это путь в никуда.

Жаль, спасибо. Интересная дискуссия, я поддерживаю использую и пропагандирую саморазвитие, иногда тоже страдаю задродством, в хорошем смысле слова. Но обычно на свой проект есть 2 - 3 часа на выходных, когда ребенок спит поэтому, тратить их на холивары о сферичечких конях нет времени да и желания. Главное во всех этих подходах понимать и оценивать, все риски и усложнения которые вызовут использование той или иной философии. Тупое следование SOLID приведет к краху проекта раньше чем проект может себе позволить. Поэтому очень часто проекты написаные на коленке работают лучше и решают свою задачу чем те которые потерялись в абстракциях. Мы говорим о высоких материях и они очень редко пересекаются с бизнессом. И потратить на разработку 100 лишних часов сегодня и избежать потери 1000 часов в будущем эторазные временные рамки для заказчика. И он выберет в 99% последнее. Ведь если разобраться то скрам тоже шлак так как приводит к быстрым релизам которые только увеличивают технический долг. Резюмируя все выше изложенное, во всем нужно разбираться, тупое следование чьим либо принципам это путь в никуда.

но мы тебе тупое и не предлагали)

мы как раз таки и акцентируем внимание на тупое следование документации например

Не важно дядя боб, фабиен или коллеги в чате :)

Всем всем спасибо за сим прощаюсь.

пока резюмирую список

- херовая дока у самой доктрины - дока симфони ориентированная на простые getting started сценарии использования - data driven подход к декомпозиции - боязнь джойнов накладывающая отпечаток на предыдущий пункт - попытки пихать в сущности логику приводят к нарушению SRP в силу предыдущих двух пунктов - желание заинджектить сервисы - "сложнее тестить" которое проистикает из веры что интеграционные тесты лучше изолированных (моки зло) или непонимание разницы - надо думать (а думать больно) - поиск и фильтрация, когда выборки в разы сложнее операций записи

а еще не всегда весь доменный слой манагается доктриной

а еще не всегда весь доменный слой манагается доктриной

ну вот у меня есть доктрина и пруф рядом

но как это влияет на логику в сущностях?

ну к примеру ордер может манагаться доктриной, а транзакции привязанные к этому ордеру приходят например из монги

а зачем ордеру транзакции?

и уже не выйдет сделать $order->pay(100);

хм...

мне кажется что ордер должен генерить инвойс а не транзакцию

а уже инвойс будет оплачен транзакцией

вдруг у тебя наличкой или карточкой

или внутренней валютой или можно вообще выбирать чем платить (хоть натурой)

ну и еще момент - как ты относишься к ивентам?)

просто как по мне платежки это отдельный контекст и он никак не должен пересекаться с непосредственно заказом

инвойс может знать айдишку заказа и стоимость, транзакция знает айдишку инвойса

когда транзакция прошла - мы можем поменять статус заказа

Поддерживаю, только ивент должен быть перед созданием invocie и после.

Поддерживаю, только ивент должен быть перед созданием invocie и после.

после чего? и зачем перед?

и мы видимо про разные ивенты

я про доменные ивенты

ERROR: S client not available

которые чуть отличаются

если я не ошибаюсь это event на уровне микросервисов?

Правильно?

типо очередей сообщений для конкретного микросервиса.

какие к черту микросервисы?

нет, погугли про domain events если интересно

в этом ключе ивент это факт - что-то что уже произошло и никуда не денется

ты не можешь никак повлиять на это

только новой какой-то операцией которая компенсирует предыдущую (вроде статусов pending + paid)

А ок не с этим не работал по гуглю.

микросервисы еще откуда-то родил

1900 сообщений за 1.5 дня, я все прочитал)

даже больше чем в ООП и PHP)

мне нравиться, у вас тут

поделюсь http://www.cs.usfca.edu/~galles/visualization/Algorithms.html

кулеры я починил, хотя они уже такими шустрыми как с завода никогда не будут(

Подскажите пожалуйста, как сделать поле уникальным и при этом nullable? Если чистый SQL будет примерно: CREATE UNIQUE INDEX UNIQ_57698A6A5E237E06 ON user (slug) WHERE user (slug) IS NOT NULL; * @ORM\Column(type="string", length=100, unique=true, nullable=true) Однако PgSQL ругаеться, что уже есть записи с NULL

из документации к постгре по интексам: > Null values are not considered equal.

так что надо смотреть где именно у тебя ругается, там уже как минимум 2-3 варианта

хорошо, буду искать, спасибо.

Считайте меня извращенцем, но учитывая, что у меня есть 3 клиента у моей API (браузерная админка, Android и IOS, при чем на каждый вид мобилки создается сразу два приложения, возможно разными разработчиками) и учитывая, что Upload через GraphQL создает необходимость выводить стандарт для всех платформ, в котором будет указано как GrapQL запрос сочетается вместе с файлами (блоб или мультипарт - без разницы), я решил не делать Upload через GrapQL вовсе. Буду открыть параллельно GrapQL еще один restfull Endpoint, с которым ни у кого не возникает вопросов и давать туда слать файлы. В ответ будут даваться имя скаченного файла или его идентификатор. Этот идентификатор я и буду уже сувать в GrapQL запрос Получается двух этапный запрос на сервер. Но в результате я имею бонус - работаю со скачанным файлом в мутациях как с полем данных, объявленным в схеме. А главеное - мне в разы меньше нужно согласований проводить с разработчиками клиентов.

Считайте меня извращенцем, но учитывая, что у меня есть 3 клиента у моей API (браузерная админка, Android и IOS, при чем на каждый вид мобилки создается сразу два приложения, возможно разными разработчиками) и учитывая, что Upload через GraphQL создает необходимость выводить стандарт для всех платформ, в котором будет указано как GrapQL запрос сочетается вместе с файлами (блоб или мультипарт - без разницы), я решил не делать Upload через GrapQL вовсе. Буду открыть параллельно GrapQL еще один restfull Endpoint, с которым ни у кого не возникает вопросов и давать туда слать файлы. В ответ будут даваться имя скаченного файла или его идентификатор. Этот идентификатор я и буду уже сувать в GrapQL запрос Получается двух этапный запрос на сервер. Но в результате я имею бонус - работаю со скачанным файлом в мутациях как с полем данных, объявленным в схеме. А главеное - мне в разы меньше нужно согласований проводить с разработчиками клиентов.

все так

http://symfony.com/doc/4.0/bundles/SensioFrameworkExtraBundle/annotations/routing.html WARNING: You are browsing the documentation for version 4.0 which is not maintained anymore. If some of your projects are still using this version, consider upgrading. Я что-то проспал? 4-я версия только появиться успела же!

SensioFrameworkExtraBundle

актуальная 5-ая версия бандла

А, так это не версия симфони? ))

не)

@fes0r В общем, посовещались с командой и перешли на твой хук cs-fixer. :D Спасибо большое ;)

напомните ссылку на хук плиз) этот тот который фиксит или не дает пушить без фикса?

Который фиксит и сразу добавляет

а скинь его еще раз, пожалуйста, сохраню себе куда-то