$this->firstTypeSubEntity + $this->secondTypeSubEntity - так в php лучше не делать

я это псевдокодом написаал

но это DRY ради DRY

имел ввиду что собираем коллекцию из всех сущностей

без какого либо смысла и только увеличивающего проблемы

так а где мне собирать коллекцию всех зависмых сущностей

если мне не веришь - дело твое, это нормально не верить. Просто задумайся когда у тебя появятся чуть более сложные кейсы, типа а вот эти сущности в коллекции трогать не надо

в методе удаления самом или как?

так а где мне собирать коллекцию всех зависмых сущностей

тебе не надо это делать

сча подправлю свой пример

если мне не веришь - дело твое, это нормально не верить. Просто задумайся когда у тебя появятся чуть более сложные кейсы, типа а вот эти сущности в коллекции трогать не надо

да я доверяю тебе) у меня нет цели победить в споре, я просто хочу понять где у меня ошибка в рассуждениях

https://gist.github.com/fesor/67ed7ca31d2b51aa7f9e17a11a23e81c

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

почему ты так думаешь? очень редко встречал тесты на каких-либо проектах

мне пока не дали на них добро

а на них надо спрашивать разрешения?

ошибка новичка

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

но ведь по факту все удаляется одинакого...сейчас у меня 6 сущностей в иерархии...а если бы их 60 было

почему ты так думаешь? очень редко встречал тесты на каких-либо проектах

у нас есть тестирвощик с итеграционными и прочими тестами, и т.к мое приложение это api то в принципе их хватает. Там есть немного юнит тестов но они дико не актуальные и самое главное что никем не запускюатся никогда. Я тесты ставил как один из первых пунктов плана, но скзаали, что сейчас раз все равно архзитектру перелопачивать будем, лучше их не писать пока

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

почему ты так думаешь? очень редко встречал тесты на каких-либо проектах

1. потому что разработчики считают что это дорого 2. это дорого потому что разработчики часто не умеют писать тестируемый код и собственно не умеют выбирать что важно тестить и как тестить

у нас есть тестирвощик с итеграционными и прочими тестами, и т.к мое приложение это api то в принципе их хватает. Там есть немного юнит тестов но они дико не актуальные и самое главное что никем не запускюатся никогда. Я тесты ставил как один из первых пунктов плана, но скзаали, что сейчас раз все равно архзитектру перелопачивать будем, лучше их не писать пока

загугли Integrational tests are a scum.

но ведь по факту все удаляется одинакого...сейчас у меня 6 сущностей в иерархии...а если бы их 60 было

разница в том что твой вариант вводит какие-то невнятные абстракции и т.д. а мой вариант проще с точки зрения восприятия - он тупой и им сложнее неправильно воспользоваться. У тебя например зачем-то открывается публичный доступ к детям. Внешнему миру не нужен этот доступ

загугли Integrational tests are a scum.

я возможно не так выразился...короче он пишет клиент на джаве к "моей" апишке типо и мокает там всё

я возможно не так выразился...короче он пишет клиент на джаве к "моей" апишке типо и мокает там всё

что именно "мокает"? апишку?)

если это тесты API то это все те же интеграционные тесты

может реально замутить пару видосиков по примеру @KuvshinovEE на тему тестов

можно

начать разницы mock vs stub

ну я сейчас со своими пробую проводить внутренние воркшопы (так себе выходит, вот второй буду в пятницу делать)

потому что иногда под словом mock многие stub юзают

ну и да разделение сделать)

потому что иногда под словом mock многие stub юзают

это да

ну и объяснить о unit, integration, acceptance

а почему это именно "ошибка новичка"?)

что у них своя ниша и свои задачи)

я думал делать такой план: 1. Юнит тесты, зачем они нужны. Пример - что-то типа калькулятора 2. Тесты с калобараторами 3. Когда не надо писать тесты

https://martinfowler.com/articles/mocksArentStubs.html

ну и объяснить о unit, integration, acceptance

я чет как-то за последние 3 месяца все больше убеждаюсь что integration тесты не нужны от слова совсем. А вот acceptance - думаю все же нужны..

но их могут QA писать

я думал делать такой план: 1. Юнит тесты, зачем они нужны. Пример - что-то типа калькулятора 2. Тесты с калобараторами 3. Когда не надо писать тесты

да это гуд идея)

я чет как-то за последние 3 месяца все больше убеждаюсь что integration тесты не нужны от слова совсем. А вот acceptance - думаю все же нужны..

ога и у меня подобное мнение

твой вопрос "моки и стабы" покрываются вторым пунктом полностью

разница в том что твой вариант вводит какие-то невнятные абстракции и т.д. а мой вариант проще с точки зрения восприятия - он тупой и им сложнее неправильно воспользоваться. У тебя например зачем-то открывается публичный доступ к детям. Внешнему миру не нужен этот доступ

короче нет у меня чуйки как грамотно выделять абстракции...да и вообще туго с принципами именно с применением...постоянно мучаюсь например как соблюсти SRP и правило не больше 3 зависимостей для одного класса. Так как если дроблю классы сильно, то у других много зависимостей появляетс, а если не дроблю, то сервисы жирненькие выходят...хз как этот скилл качать

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

короче нет у меня чуйки как грамотно выделять абстракции...да и вообще туго с принципами именно с применением...постоянно мучаюсь например как соблюсти SRP и правило не больше 3 зависимостей для одного класса. Так как если дроблю классы сильно, то у других много зависимостей появляетс, а если не дроблю, то сервисы жирненькие выходят...хз как этот скилл качать

а как ты понимаешь SRP?

одна ответственность на класс/компонент...или у класса одна причина на изменение. Под одной причиной имею ввиду изменение в поведении какой то одной операции, необязательно выраженной одним методом

у меня в ближайшее время сделать норм плейлист по ER

чтобы было прямо норм с нуля, ото стрим получился слишком сумбурный

начать с нотаций Чена

потом про Crow foot

показать их и сказать что это лишь способ визуализации связей

ну и про типы связей в самомм начале между entity

и далее по тихоньку на практику, уже с примерами в mysql пергнать бд в -> ER схему Перегнать ER схему -> В БД

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

одна ответственность на класс/компонент...или у класса одна причина на изменение. Под одной причиной имею ввиду изменение в поведении какой то одной операции, необязательно выраженной одним методом

причина для изменений всегда люди

ты хочешь поменять код не потому что "надо поменять код" а потому что "кому-то надо что бы код поменялся"

и вот если ты можешь придумать 2-х людей которые захотят изменений в одном модуле - надо дробить

ни код а поведение системы, ты имелл ввиду)

и да, менеджеров и аналитиков просят другие челы - то есть надо всю цепочку раскручивать

ни код а поведение системы, ты имелл ввиду)

ну да, поведение. На код всем плевать

и вот если ты можешь придумать 2-х людей которые захотят изменений в одном модуле - надо дробить

а не кажется ли что это вызовет слишком большую декомпозицию?)

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

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

+++

в том числе и багфикс - исправление поведения

ERROR: S client not available

а не кажется ли что это вызовет слишком большую декомпозицию?)

а у тебя много ролей на проекте? на моем опыте самое большое количество ролей "пользователей" которые могут хотеть что-то изменить в поведении системы - 7

ну короч это очень субъективная штука, она хороша как раз таки что бы не пере-DRYить

сталкивался со всякими штукамми

типо менеджер

контроллер менеджера

ну это просто херовые нейминги

и ад с зависимостями

в крупной системе было дофига ролей и все умножалось на 2 (контроллеры)

и нарушение open/close

типо есть отделение банка и там есть рабочие и контроллер банка

в крупной системе было дофига ролей и все умножалось на 2 (контроллеры)

дофига это сколько?

есть уровень города

таже история

есть уровень региона

далее уровень федерального округа

ну это не роли - это уровни. У тебя есть некое поведение системы которое кому-то нужно

и вот важно кому

и на глобальном уровне небольшой адок)

но в целомм цифра 7 да довольно точна)

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

и да, менеджеров и аналитиков просят другие челы - то есть надо всю цепочку раскручивать

Дядя боб это хорошо объяснял до уровня chief officer, какой C*O будет недоволен

или вот другая система там тоже адища с ролями была

около 27 было

плюс доступы по географии

Но это частный случай работы в больших корпорациях

типо роль и группа доступа (филиал, регион, федеральный округ, глобальный)

Дядя боб это хорошо объяснял до уровня chief officer, какой C*O будет недоволен

да, "кто будет тебя увольнять если ты сломаешь этот модуль, и если возможны больше одной кандидатуры - у тебя проблемы с декомпозицией")

я вот все так и не дочитал книжку

Responsibility Driven Design

Not been fired driven development

Designing Object Oriented Software