про фабрики разговор отдельный

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

всё что можно сделать на моей стороне - сделано. переписывать чужие либы - не про меня

в краце проблема в инжекте вложенных объектов и их конфигурация

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

причём объекты классов из разных либ, которые спроектированы абсолютно поразному) и их нужно проинтегрировать

и фабрика эту проблему инкапсулирует

и эта проблема еще не скоро решится. С одной стороны все логично, одни объекты принимают другие объекты, которые уже сконфигурированы, т.е. их каждый нужно отдельно конфигурить. И то что либы разные по разному работают и конфигурируются и интегрируются - это тоже нормально. Нормально пока единого стандарта нет.

это блин и есть основная задача разработки решений - взять А и Б и заставить работать вместе.

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

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

ну вот пример - есть у тебя http запрос. Стал бы ты его пихать в DI?

он же доступен только в момент запроса. С другой стороны - стал бы ты в http запрос пихать другие зависимости?

может быть стоит распределить ответственность по другому?

не, параметризованный контейнер из запроса - это чушь какая-то

короч я вижу проблему только с тем что в контейнер хочется запихнуть что-то явно не то

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

Есть какие-то best practices для тестирования абстрактных классов?

эээ

а что там тестировать, он же абстрактный?

каждому абстрактному классу по абстрактному тесту

если он юзается просто как интерфейс - там и тестировать нечего. если как хранилище для чистых функций - их и тестируй. если как частичная реализация для переиспользования кода - тестируй наследников.

а вообще странный вопрос

если он юзается просто как интерфейс - там и тестировать нечего. если как хранилище для чистых функций - их и тестируй. если как частичная реализация для переиспользования кода - тестируй наследников.

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

норм

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

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

Есть какие-то best practices для тестирования абстрактных классов?

не тестировать их. И не использовать

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

не тестировать их. И не использовать

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

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

нет, я советую делать абсолютно противоположное)

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

а чем плохи абстрактные классы?)

изо дня в день 1 и тот же наброс) уже сродни "конструктор - это метод?")

нет, я советую делать абсолютно противоположное)

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

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

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

У меня другая проблема, я не могу найти человека, который бы объяснил чем они хороши.

У меня другая проблема, я не могу найти человека, который бы объяснил чем они хороши.

да они ни чем не хороши, ни чем не плохи) они есть, ими можно решать задачи просто и понятно. Без всяких накручиваний в угоду "правильному ооп")

если от них можно избавится, от них лучше избавится

потому что гладиолус?)

потому что гладиолус?)

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

ну по моему опыту

сломать как?)

изменяя код, вестимо

ну приведи пример того, что и как ты ломаешь. Я пока не представляю о чём ты

привести пример как можно сломать дочерний класс изменив что то в родителе?

а ещё можно пару файлов удалить, да)

это не проблема абстрактных классов, если что

донный наброс в общем

как хочешь

не, я понимаю, что модно нынче накидывать) но аргументация хромает.

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

Окей, а если тебе надо переиспользовать код. Ты не хочешь абстрактных классов. Берешь композицию. Меняешь класс, который содержит общий функционал и вжух, ты снова всё сломал. Без абстрактных классов. В чём проблема-то?

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

Руки тоже можно сломать, это не повод ими не пользоваться.

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

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

я не писал "можно сломать" я писал "легче сломать" и добавил что "по моему опыту". Нет статистики у меня нет.

может быть у вас другой опыт

ну приведи пример того, что и как ты ломаешь. Я пока не представляю о чём ты

LSP?

ну т.е. goto тоже можно с умом юзать

LSP?

и как он должен нарушаться?)

и эксепшены

и как он должен нарушаться?)

его гораздо легче нарушить используя наследование

это не значит, что используя абстрактные классы ты его нарушаешь

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

да

точно также как goto

плохо только потому, что ментальная нагрузка растет очень сильно

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

я ж не сказал, что говно идет только от наследования

и что у наследования нет юз-кейсов

а я не говорил, что композиции надо предпочитать наследование :) но что реально не нравится - это то, что все повторяют, мол, наследование - это плохо. Потому, что .... (подставить своё. Обычно вместо многоточия чушь какая-то)

а я не говорил, что композиции надо предпочитать наследование :) но что реально не нравится - это то, что все повторяют, мол, наследование - это плохо. Потому, что .... (подставить своё. Обычно вместо многоточия чушь какая-то)

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

как много людей объяснит, чем плох goto?

да хер знает, плох ли он)

ты там выше верно заметил: в большинстве случае всё зависит от того, кто инструмент в руках держит)

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

А что тут объяснять, код становится unmaintable

схера ли?

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

да хер знает, плох ли он)

- первоисточник: https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf - разбор по первоисточнику: временно недоступен :( - http://wiki.c2.com/?GotoConsideredHarmful

- первоисточник: https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf - разбор по первоисточнику: временно недоступен :( - http://wiki.c2.com/?GotoConsideredHarmful

пасиб, глну на досуге

жаль что разбор этой статьи недоступен... даже в гугл кэше

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

это конечно не значит, что не существует иной модели, где это все легко анализируется)

не существует = невозможно построить

и тебе спасибо)

https://web.archive.org/web/20180310093810/david.tribble.com/text/goto.html

нашел, вот это

пинг

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

Итак, у нас имеется некая хранимка, которая формирует список "действий" для интерпретатора

хранимка проходит по куче таблиц со связями и формирует выходной список действий

xml, но это не важно - интерпепретатор на стороне потребителя пока поддерживает только "линейный спискок действий "

в настоящий момент поддерживаются "вызовы" подпрограмм только без параметров

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