Грубо конечно, но мне тоже кажется что профессионализм яндексовских программистов под вопросом) Они с первого раза не могли удалить историю из аккаунта, только с 3 раза получилось все подчистить)) смешно и грустно)
Уже больше года как забыл про сервисы яндекса, теперь не смотрю по 5 реклам подряд в кинопоиске, меня не обдирают подписками на аккаунты которые я не создавал, вообщем стало жить чуточку спокойнее)
Вы сужаете целые главы книг до одной фразы и спрашиваете весь ли это смысл? Мне кажется очевидно что нет.
Я через день пишу на чистом js фронт, мне на нем не приходилось, пока, строить сложные вещи, но я уверен что если погрузиться в этот вопрос глубже, инверсия зависимости подругому реализуется, возможно напишу про это что-то))
Системный аналитик должен знать что такое инверсия зависимости?) Или, например, почему в луковичной архитектуре стрелочки зависимостей рисуют к домену? То есть более низкоуровневый код должен зависить от более высокого?) Ну это, как будто, должны программисты знать) Почему домен не должен зависить от базы данных))
Хотя мне в комментариях один тимлид ВК высказывал что им никакая инверсия не нужна и это все кодовое графоманство) Ну я хочу сказать что и приложение ВК не лучший пример для подражания)) Да и акции уже по 130 рублей или сколько там))
В языке где есть интерфейс достаточно написать implements (например php) и быть уверенным что ваши репозитории поддерживают контракт.
Я в примере обращал ваше внимание, что интерфейс зарождается в коде потребителя. Это справедливо для любого ЯП
Получается вы как веб разработчик считаете что для домена (бизнес логики) интерфейс задают потребители бизнес логики? Интересно как.
А так вам просто нужно место (файл), где описать какой-то интерфейс в том или ином виде, предусмотренным соответствующим ЯП, или в md- или txt-файле, если этот ЯП ещё менее развит, чем JS с его JSDoc
Поймите, для меня как программиста это просто не приемлемо. Сидеть и сверять программу с текстом, когда за выполнением контрактов должен отвечать компилятор/интерпретатор это явно два шага назад
Я вам и пытаюсь сказать что нету никакого контракта у вас.
Получается что ваши репозитории должны знать тело каждой функции и что в ней может быть вызванно. Ладно один пример, учебный, но на реальном проекте это сразу превратится в барьер
Даже наследование класса и переопределение метода выглядит лучше чем "просто знать" где там что вызывается
Я имел ввиду которыми люди пользуются на постоянную. Это ведь новая эра разработки, быстрая проверка мвп, где эти быстро проверенные мвп которые нашли свою нишу?
То что куча шлака появилось, в этом я не сомневаюсь, или новая эра качества нам не обещает?((
Грубо конечно, но мне тоже кажется что профессионализм яндексовских программистов под вопросом) Они с первого раза не могли удалить историю из аккаунта, только с 3 раза получилось все подчистить)) смешно и грустно)
Уже больше года как забыл про сервисы яндекса, теперь не смотрю по 5 реклам подряд в кинопоиске, меня не обдирают подписками на аккаунты которые я не создавал, вообщем стало жить чуточку спокойнее)
У меня тоже не получается вам объяснить что сократить до одной фразы понятие из книги нельзя)) Не учитывая что и фразу вы приводите не ту))
Спасибо за мотивацию разобраться)
Если бы тс выполнялся в браузере, без проблем я бы лучше его взял.
А так, покрасить кнопочки, отправить ajax, мне хватает с лихвой. Бизнес логики никакой нет на фронте.
Серьёзность проекта показывает результат, а не библиотеки
Вы сужаете целые главы книг до одной фразы и спрашиваете весь ли это смысл? Мне кажется очевидно что нет.
Я через день пишу на чистом js фронт, мне на нем не приходилось, пока, строить сложные вещи, но я уверен что если погрузиться в этот вопрос глубже, инверсия зависимости подругому реализуется, возможно напишу про это что-то))
Ну я согласен что от неиспользуемых интерфейсов зависимость не нужна, это вроде очевидно.
Вы вырвали одну фразу, которая к делу, по сути, даже не относится, из книги где нужно последовательно читать главы чтобы все собрать в одну картину...
Я вас не хочу ни в чем переубедить. Я использую инверсию зависимости в своих проектах и придти к пониманию мне помогла эта книга.
Подробно можно прочитать в книге Роберта Мартина "Чистая архитектура"
Ну я тоже хорошо представляю откуда берутся требования.
По вашему разделение интерфейса на более мелкие, функциональные части, это построение инверсии зависимости??
Segregation как раз переводится как разделение, и не как не связанно с направлением требований...
Системный аналитик должен знать что такое инверсия зависимости?) Или, например, почему в луковичной архитектуре стрелочки зависимостей рисуют к домену? То есть более низкоуровневый код должен зависить от более высокого?) Ну это, как будто, должны программисты знать) Почему домен не должен зависить от базы данных))
Хотя мне в комментариях один тимлид ВК высказывал что им никакая инверсия не нужна и это все кодовое графоманство) Ну я хочу сказать что и приложение ВК не лучший пример для подражания)) Да и акции уже по 130 рублей или сколько там))
Понял, вопросов больше не имею
В языке где есть интерфейс достаточно написать implements (например php) и быть уверенным что ваши репозитории поддерживают контракт.
Получается вы как веб разработчик считаете что для домена (бизнес логики) интерфейс задают потребители бизнес логики? Интересно как.
Поймите, для меня как программиста это просто не приемлемо. Сидеть и сверять программу с текстом, когда за выполнением контрактов должен отвечать компилятор/интерпретатор это явно два шага назад
Я вам и пытаюсь сказать что нету никакого контракта у вас.
Получается что ваши репозитории должны знать тело каждой функции и что в ней может быть вызванно. Ладно один пример, учебный, но на реальном проекте это сразу превратится в барьер
Даже наследование класса и переопределение метода выглядит лучше чем "просто знать" где там что вызывается
Получается и выкинуть ошибку, а вместе с ней и завалить все приложение, из-за не существуешго метода, тоже право функции?
Реально в js нет интерфейсов... ну это надо как-то проверять тогда в коде чтоли...
мда, жесть конечно, язык как будто для маленьких манипуляций с html сделали, а не для серьёзных проектов...
Странно что вас ничего не смущает.
Откуда у вас уверенность что repository имеет функцию findNameById, которую вы вызываете в методе?
Ага, учитывая что тип можно указать в сигнатуре функции и зависимость тоже будет явная, без всяких DI...
DI это про контейнер который содержит объекты для инъекции, а не про инверсию зависимостей...
Промазал комментарий))
Ваша идея это ActiveRecord, не самый лучший паттерн, по моему мнению.
Я имел ввиду которыми люди пользуются на постоянную. Это ведь новая эра разработки, быстрая проверка мвп, где эти быстро проверенные мвп которые нашли свою нишу?
То что куча шлака появилось, в этом я не сомневаюсь, или новая эра качества нам не обещает?((