Как вы относитесь к такой болезни ООП как AbstractFactoryBuilderBean?

Как вы относитесь к такой болезни ООП как AbstractFactoryBuilderBean?

развивающие игры, ну те что на воорбажение ориентированы

это билдер абстрактных фабрик или абстрактный билдер фабрики?

билдер абстрактный фабрик + бесполезный суфикс

в целом же названия типов объектов должны передавать что делают объекты

тут этого нет

с помощью этого объекта можно создать любую фабрику

с помощью этого объекта можно создать любую фабрику

ну то есть работает оно как new AnyFabric?

что значит "любую"?

так не бывает

ну то есть работает оно как new AnyFabric?

это абстрактный объект, ты не можешь его создать

сперва надо заэкстендиться

мы тут знаете ли плохо к наследованию относимся)

абстрактная фабрика это вообще нечто странное

какой у нее публичный интерфейс?

абстрактная фабрика это на самом деле прекрасный пример компромисов

это тот случай когда избавиться от if-в не выходит)

public НепонятноЧто createObject() ?

ну у тебя у всех "непонятно что" есть общий базовый тип

а за счет принципа подстановки Барбары Лискоу тебе этого должно хватать

CreatableByAbstractFactoryInterface?

ээм... нет

ну например

AbstractButton, да?

ButtonInterface

ну тип того

только давай без суффиксов/постфиксов бесполезных

просто Button

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

фабрика строит инстансы нужных типов исходя из входящих данных

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

то есть фабрика вполне конкретная?

у нее есть инстанс?

конкретная фабрика которая делает абстракции

почему тогда не назвать ее просто ButtonFactory?

> у нее есть инстанс? хз, я обычно это делаю в статическом методе в базовом классе

почему тогда не назвать ее просто ButtonFactory?

норм название для абстрактной фабрики че

у меня к тебе встречный вопрос

почему ты не назовешь ProductRepository не как Catalog

?

"прудукты хранятся в каталоге" звучит как-то логичнее с точки зрения бизнеса нежели "продукты лежат в репозитории продуктов"

а почему я не назову? может и назову. просто Repository имеет некую дополнительную смысловую нагрузку

ассоциации в голове всплывают

точно так же Abstract имеет некую смысловую нагрузку)

которая несет ровно ту же 0-вую ценность

ну не

ну да)

Catalog может быть каталогом кнопок, а может быть каталогом лягушек

ты сразу будешь думать "о репозиторий... доктрина... дата мэппер... запихну туда findProductsWithComments

а ProductRepository понятно что хранит продукты

Catalog может быть каталогом кнопок, а может быть каталогом лягушек

каталог в контексте e-comm солюшена не может быть "каталогом кнопок"

хотя может и может но тогда "кнопка" это продукт в каталоге)

ну да

фронтендом запахло

я это к тому что разработчики думают не в терминах бизнеса

как правило

и это заставляет их обзывать вещи как им удобно

фронтендом запахло

просто классический пример с кнопками

я это к тому что разработчики думают не в терминах бизнеса

Ну, не соглашусь

Ну, не соглашусь

я не про всех

я про подавляющее большинство

и еще большее количество людей обзывая что-то SomethingInterface делают это на автомате

ну то есть их лет 10 назад так научили и они с тех пор так делают

привычка

знаете же эксперемент с обезъянками и бананом?

знаете же эксперемент с обезъянками и бананом?

"откуда пошли традиции"?

ERROR: S client not available

https://dezinfo.net/images3/image/02.2012/obezyan/1003.jpg

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

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

а бизнесу нужны твои абстракции?)

а бизнесу нужны твои абстракции?)

Не, я ж лично для себя и для команды. Чтоб архитектуру строить

И чтобы не получилось 800 уровней наследования

Фаьрик тыщщи, паттерн на паттерне и все такое

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

вот надо этому учится

мой подход не приносит пользы

Не, я ж лично для себя и для команды. Чтоб архитектуру строить

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

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

почитай про функциональную абстракцию

декомпозицию и т.д.

говорят помогает

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

они сначала делают и потом уже задают вопросы когда "не работает"

потому такие практики как TDD и выдумывают

они заставляют разработчика вникать и разбираться что им нужно сделать...

(воприки мнению что это про тесты)

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

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

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

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

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

но если ты сделаешь это ДО у тебя не будет тратиться время на этот огромный метод

хотя прототипы делать иногда полезно

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

так с точки зрения времени и трудозатрат эффективнее выходит

1 час на жирный метод, 0.25 часа подумать, 0.5 час тест, 0.5 час реализация

0.25 часа подумать, 0.5 час тест, 0.75 час реализация

что быстрее?

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

Иногда эффективен иногда - нет. Бывает что бизнкс требования свои сам не понял, бывает я накосячил.

0.25 часа подумать, 1 час реализация, 0.5 часа тест, 0.25 часа рефакторинг кода что бы тесты норм писались, 0.25 часа дописать тесты

Иногда эффективен иногда - нет. Бывает что бизнкс требования свои сам не понял, бывает я накосячил.

для первого - есть BDD, а второе это нормально