Ну вообще говорили, что даже кресла из гражданских автомобилей не подходят как образец для кресел офисных. А это не так. Популярной переделкой является использование гражданских автокресел в качестве офисных.
Не делайте этого. В случае холлов хоть используется MX стандарт свитчей и их производит тот же гатерон. А все оптические свитчи так или иначе отдельная разработка компаний. Смысла ноль.
Каждый раз когда я вижу нужно отказаться от ORM люди не понимают зачем они нужны. Они просто занесли их в проект потому что все так делают. Если ORM мешается вам на проекте перестаньте его использовать. Сила ORM проявляется только когда у вас 100500 CRUD есть с которыми вам надо работать. Плюс уменьшаются накладные расходы на DTO. Если же у вас этого всего нет зачем вы тащите в проект ORM?
Единственный верный вариант решать этот вопрос в СУБД. Она для этого и была придумана. Там из коробки ACID реализован, а вы спрашиваете как его в DDD реализовать. А зачем?
В очень даже компилируемом C стандартная библиотека(да и не только она) поставляется в двух вариантах. В продуктовом и версии 'для отладки', где в реализации больше напихано и не выкинуто всяких полезностей именно для разработки. И в зависимости от режима компиляции/среды линкуется нужная.
Ну вообще там просто debug символы при линковке режутся и все. А сами по себе библиотеки одинаковые.
Интерфейс же и замена через него реализаций, универсально и используется во многих языках. Это дешевле так-как вероятность того что программист уже пользовался таким выше. Особенно это актуально в компилируемых языках. Подход замены же который предлагается это больше про динамические языки. И там вот интерфейсы для тестирования можно и не использовать так-как подмена делается существенно проще.
Да можно. Только это не упрощает, а усложняет жизнь программисту. Вместо явного указания тут будет интерфейс и тут мы ожидаем что будет подмена реализации, это выносится на уровень рантайма и линковки. А это надо будет еще раз где-то описывать и показывать. В чем смысл? Чтобы просто кушать не могу убрать интерфейс? Ну дак лучше то не становится.
А зачем вы в своем приложении полагаетесь на интерфейсы которые вами не управляются? Если я подключаю внешнюю зависимость и не уверен в ее стабильности (а это чаще всего так), то отделяю эту зависимость своим интерфейсом. Далее если IndiaPayment поменяет метод, то мне нужно будет это править ровно в одном месте который осуществляет связывание с IndiaPayment и не заниматься рефакторингом всего проекта.
Какие еще удары? Вы вообще про что? Руки на руле ну да ну да. Между тем в автомобиле есть подлокотники в том числе для водителя. Потому что большая часть водителей все равно держат одну руку на руле вместо двух. Боковые поддержки в поворотах? Я не зря про гражданские автомобили сказал. Там это не сказать что очень требуется. По моему опыту боковые поддержки больше полезны на пересеченной местности чем в поворотах.
Подогрев это опция как и вентиляция и вообще отношения к вопросу не имеют.
В общем сидение за рулём кардинально отличаться от сидения за клавой.
Ни что так не выдает теоретика, как вот такие глубокие заключения. Гражданское автосидение предназначено в том числе и чтобы в нем долго сидеть. И вы удивитесь но правильная посадка что за компьютером что за рулем очень мало отличается. И да люди ездят и на дальние расстояния и работают экспедиторами и проводят по 10 часов за рулем.
В хорошем автосидении сильно больше регулировок в том числе и для комфортного сидения, даже самые шикарные компьютерные кресла до этого уровня не дотягивают. Банально у автомобильного кресла регулируется наклон спинки, поясничный упор, длина сидения, наклон сидения, высота сидения.
Особенно непонятно зачем это делать для программы на Go, где зачастую интерфейс можно прикрутить в любой момент позже (там "классы" не требуют указания "implements").
Для тестов. Добавляете интерфейс и вуаля вы можете подсовывать mock реализации и тестировать поведение.
Ну вообще говорили, что даже кресла из гражданских автомобилей не подходят как образец для кресел офисных. А это не так. Популярной переделкой является использование гражданских автокресел в качестве офисных.
На станции есть надпись С115 в описании T12 я про это если не понятно.
Эммм. Формат жал T12 на фото жала формата C115. Кажется тут ошибка в описании жал станции.
Не просто глубина срабатывания, там же аналоговый датчик. Плюс он не зависит от загрязнений. Оптический зависит.
они производятся как правило под одну определенную клавиатуру. Опять же если выбирать между холл и оптика, лучше брать холл.
Зарядник прям на контроллере. Достаточно подключить usb к контроллеру.
Есть варианты контроллеров в виде модулей. Вопрос исключительно в ваших силах. Уверены ставьте.
Не делайте этого. В случае холлов хоть используется MX стандарт свитчей и их производит тот же гатерон. А все оптические свитчи так или иначе отдельная разработка компаний. Смысла ноль.
Каждый раз когда я вижу нужно отказаться от ORM люди не понимают зачем они нужны. Они просто занесли их в проект потому что все так делают. Если ORM мешается вам на проекте перестаньте его использовать. Сила ORM проявляется только когда у вас 100500 CRUD есть с которыми вам надо работать. Плюс уменьшаются накладные расходы на DTO. Если же у вас этого всего нет зачем вы тащите в проект ORM?
Единственный верный вариант решать этот вопрос в СУБД. Она для этого и была придумана. Там из коробки ACID реализован, а вы спрашиваете как его в DDD реализовать. А зачем?
Ну вообще там просто debug символы при линковке режутся и все. А сами по себе библиотеки одинаковые.
Проблема подмены в ее неявности.
Интерфейс же и замена через него реализаций, универсально и используется во многих языках. Это дешевле так-как вероятность того что программист уже пользовался таким выше. Особенно это актуально в компилируемых языках.
Подход замены же который предлагается это больше про динамические языки. И там вот интерфейсы для тестирования можно и не использовать так-как подмена делается существенно проще.
Да можно. Только это не упрощает, а усложняет жизнь программисту. Вместо явного указания тут будет интерфейс и тут мы ожидаем что будет подмена реализации, это выносится на уровень рантайма и линковки. А это надо будет еще раз где-то описывать и показывать. В чем смысл? Чтобы просто кушать не могу убрать интерфейс? Ну дак лучше то не становится.
А интерфейс потребуется чтобы заменять класс-адаптер на тестовую тупиковую реализацию. Чисто практический смысл.
А зачем вы в своем приложении полагаетесь на интерфейсы которые вами не управляются? Если я подключаю внешнюю зависимость и не уверен в ее стабильности (а это чаще всего так), то отделяю эту зависимость своим интерфейсом. Далее если IndiaPayment поменяет метод, то мне нужно будет это править ровно в одном месте который осуществляет связывание с IndiaPayment и не заниматься рефакторингом всего проекта.
в статической. В других языках с ней же у вас будет такая же схема. Если что в javascript тоже утиная типизация.
Какие еще удары? Вы вообще про что? Руки на руле ну да ну да. Между тем в автомобиле есть подлокотники в том числе для водителя. Потому что большая часть водителей все равно держат одну руку на руле вместо двух. Боковые поддержки в поворотах? Я не зря про гражданские автомобили сказал. Там это не сказать что очень требуется. По моему опыту боковые поддержки больше полезны на пересеченной местности чем в поворотах.
Подогрев это опция как и вентиляция и вообще отношения к вопросу не имеют.
Ни что так не выдает теоретика, как вот такие глубокие заключения. Гражданское автосидение предназначено в том числе и чтобы в нем долго сидеть. И вы удивитесь но правильная посадка что за компьютером что за рулем очень мало отличается. И да люди ездят и на дальние расстояния и работают экспедиторами и проводят по 10 часов за рулем.
В хорошем автосидении сильно больше регулировок в том числе и для комфортного сидения, даже самые шикарные компьютерные кресла до этого уровня не дотягивают. Банально у автомобильного кресла регулируется наклон спинки, поясничный упор, длина сидения, наклон сидения, высота сидения.
В golang статическая типизация. Самый простой вариант в таких случаях это как раз интерфейс и замена реализации через него.
Простите что значит моки под что угодно? Реализацию моков как подсовывать будете?
Для тестов. Добавляете интерфейс и вуаля вы можете подсовывать mock реализации и тестировать поведение.