Минимизироваться должна связка {количество компонентов, сложность каждого компонента, количество связей конкретного компонента, общее количество связей, длина пути между функционально связанными компонентами, наверняка что-то ещё}.
Архитектуру можно считать относительно успешной, если интегральный рост этих метрик медленнее, чем функциональность проекта.
Дальше может быть дискуссия как это всё считать, но я бы не хотел открывать этот ящик Пандоры.
В ядре любой ОС это основная концепция для реализации полиморфных объектов, коих пруд пруди даже в ядре. Например, попробуйте реализовать поддержку разных файловых систем без этого. Да хотя бы файловой системы с каталогами и файлами.
Вы таки считаете, что ситуации, когда это может понадобиться, не может быть?
Пример: многопользовательское приложение, для разных групп пользователей нужно по-разному предоставлять сервисы через DI. Билдер определяет правила для фабрики, которая будет создавать на каждого пользователя свой дочерний контейнер.
Ох, доводилось мне видеть компоненты, которые писали джуны "на один раз", которые (джуны в смысле) сбегали через годика полтора-два. Собственно, если ты раз в два года меняешь работу в очередной стартап, то не просто успеваешь застать долгоживующие компоненты.
ООП, ФП с монадами, SOLID и прочие практики нужны для того, чтобы в первую очередь управлять сложностью. И они не приносят пользы при отсутствии сложности. Поэтому нет смысла приводить примеры, где нет сложности - они будут абсурдными. Что и получилось в этой статье.
Хантинг в вузах имеет место быть и имеет свои плюсы и минусы для всех сторон, но плюсов в среднем больше: толковые скромные получат работу, работодатель экономит на отборе и, возможно, на подготовке, препода тоже можно прикармливать каким-то образом кроме морального удовлетворения.
Минусы тоже есть, но они, скорее, ситуативные: меньшая инициативность тех, кто уже пристроен, злые языки могут препода назвать продающим рабов, пролетающие могут иметь зуб на него и т.п.
Минимизироваться должна связка {количество компонентов, сложность каждого компонента, количество связей конкретного компонента, общее количество связей, длина пути между функционально связанными компонентами, наверняка что-то ещё}.
Архитектуру можно считать относительно успешной, если интегральный рост этих метрик медленнее, чем функциональность проекта.
Дальше может быть дискуссия как это всё считать, но я бы не хотел открывать этот ящик Пандоры.
... а потом не запутаться в их композировании обратно
Что-то созвучное с анекдотом "Разум на Земле - величина постоянная. А население растёт."
Скорее так: слишком простой код вряд ли будет полезным.
В ядре любой ОС это основная концепция для реализации полиморфных объектов, коих пруд пруди даже в ядре. Например, попробуйте реализовать поддержку разных файловых систем без этого. Да хотя бы файловой системы с каталогами и файлами.
Вы таки считаете, что ситуации, когда это может понадобиться, не может быть?
Пример: многопользовательское приложение, для разных групп пользователей нужно по-разному предоставлять сервисы через DI. Билдер определяет правила для фабрики, которая будет создавать на каждого пользователя свой дочерний контейнер.
https://habr.com/ru/articles/258825/
Если начинать любой проект с вот этого, получится примерно то же самое:
-- мне просто надо сложить два числа!
-- подожди, надо сначала определиться с концепцией числа!
А Вы уверены, что то решение не было написано чьей-то кровью на стене?
Особенно если на ящиках нормально написано, что в них лежит.
Ох, доводилось мне видеть компоненты, которые писали джуны "на один раз", которые (джуны в смысле) сбегали через годика полтора-два. Собственно, если ты раз в два года меняешь работу в очередной стартап, то не просто успеваешь застать долгоживующие компоненты.
ООП, ФП с монадами, SOLID и прочие практики нужны для того, чтобы в первую очередь управлять сложностью. И они не приносят пользы при отсутствии сложности. Поэтому нет смысла приводить примеры, где нет сложности - они будут абсурдными. Что и получилось в этой статье.
Хантинг в вузах имеет место быть и имеет свои плюсы и минусы для всех сторон, но плюсов в среднем больше: толковые скромные получат работу, работодатель экономит на отборе и, возможно, на подготовке, препода тоже можно прикармливать каким-то образом кроме морального удовлетворения.
Минусы тоже есть, но они, скорее, ситуативные: меньшая инициативность тех, кто уже пристроен, злые языки могут препода назвать продающим рабов, пролетающие могут иметь зуб на него и т.п.
Вот и славно, что мы придерживаемся одного мнения.
Вы видите в этом что-то плохое?
Вот только симпатичная девочка имеет исключительно меркантильные интересы.
Как только клиент на борту - он становится исключительно статистической единицей.
Выглядит будто у девушки запасная жизнь есть...
С другой стороны, разработчики на не-мейнстримных языках с претензиями готовы говорить об этом постоянно.
Скрытый текст
Тема HR-ов на сайтах знакомств не раскрыта.
Есть три модели поведения:
невероятная: HR не распространяется об этом как минимум на старте и не задаёт вопросов, чтобы не получить встречный
импринтинговая: HR обращает больше внимания на знакомый в плане поведения контингент. Дальше возможны варианты, описанные в заключительной части
канцерогенная: HR ведёт в личной жизни себя тоже как HR. В любом случае развивается рак, вопрос лишь в том, какого "органа".
Это демонстрация накопления технического долга: его никто не видит, пока кто-то на него не укажет.
Из особенного - если есть массив @x, то $x - его длина. Или если %x - это хэш-таблица, то $x - её длина.