Жизненно важно — наверно нечасто, к сожалению я теоретик, за пределы хеллоу ворлдов не выходил, так что примеров как за, так и против не привел бы, но выглядит это комфортнее как то для восприятия. По крайней мере если у нас нет другого явного способа выделить при чтении интерфейсы отдельно.
Черт, серьезно? Когда читал внимания не обратил, пусть даже в используемой мной платформе нет ООП, но странно что я это пропустил. А там нет уточнения что это для случаев когда интерфейс — это элемент языка, или что то в таком духе (к сожалению книга не под рукой сейчас)? Просто этот пункт странным кажется.
Имхо, тут как с паттернами, можно пытаться каждый раз объяснять просто (не факт что конкретный человек это сумеет, и не введет в заблуждение), а можно использовать общепринятую терминологию вроде тех же названий принципов в статье описанных, или ранее упомянутых мной паттернов. Общий словарь все же коммуникацию упрощает (меньше ошибок, неоднозначностей, слов, абстракция содержит больше полезных идей и меньше мусора, ну, в идеале).
Понять что есть лямбды нужно один раз, и дальше этот разработчик вполне будет читать код, так что код будет все еще прост. А вот всякие нагромождения тернарных операторов в тернарных операторах, или десятки параметров метода на километр — когнитивную нагрузку создают очень значительную, и каждый раз когда встречаются, и неважно что концепция разработчику знакома. Я бы уточнил формулировку из комментария выше:
код, который может понять даже человек не знакомый с этим конкретным языком программирования
, в случае знания концепций с использованием которых он был написан.
Брр, скайп полный трэш. По моим ощущениям он разве что на флагманах работать нормально будет, и то не факт. Впрочем скайп для десятки — тоже тот еще трэш.
Сейчас я бы тоже так сделал, или ВК написал бы, а скорее всего изначально бы упорнее пинал тех кто за шину отвечает, что они неправы когда говорят про присылают utf-8. Но когда ты джун который и года не проработал и тебе дают готовое решение генподрядчика которое у них где то уже работает — меньше всего будешь заниматься такими вещами.
К сожалению нет, давно было, к тому же потом выяснилось что необходимость перекодирования — из за настроек шины возникла, соответственно код этот выкинули после изменения настроек.
Был как то случай, из ком объекта массив байтов получали в кривой кодировке, так что в цикле их крутили, немного меняли значения. Бывало цикл со сложением внутри выполнялся несколько часов на 20-30кк операций.
Вот мы и вернулись к тому что все равно где то нужно фиксировать какие данные мы выгрузили и как то получать информацию что загрузка прошла успешно. И тут можно прикрутить что то свое, но лучше для упрощения все же платформенные методы использовать.
Для этого нужно получить подтверждение от мобилки что предыдущая пачка загружена, к тому же это может произойти не скоро, нужно хранить где то (либо ключи с мобилки возвращать) какие данные с регистрации снять. Да еще и убедиться что с прошлой выгрузки эти данные снова не менялись… В общем механизм тех же планов обмена с нумерацией сообщений и т.п. переизобретать. Зачем?
Ну ок, выгрузили в файл (впрочем с мобилкой файлы использовать очень странно, логично когда обмен напрямую через http), а файл кто то повредил или удалил. И что делать с потерянными данными?
Тогда так. Вот было бы здорово, если бы функция «ПланыОбмена.ВыбратьИзменения» принимала максимальный размер выбираемой пачки. Не сразу всё, что там накопилось, а например пачичку в 100 штук. На следующей итерации – ещё 100 штук. И так далее. Она и отрабатывать будет быстрее, если изменений много образовалось. И блокировать будет недолго.
Мы у себя реализовывали подобный механизм для обмена с мобилкой (тоже на 1с через планы обмена). Методу ВыбратьИзменения можно передать массив содержащий только часть данных, а массив можно получить из таблиц изменений. Выглядит в результате это так себе, но работает.
Но это по сути уже эмуляция средств языка путем соглашений, не лучше ли непосредственно определять интерфейс чем добавлять подчеркивания в имена свойств и методов? Конкретный пример приведенный плох еще тем что по умолчанию подразумевается что все методы и свойства публичны, что не есть хорошо.
Но отсутствие контрактов не означает отсутствия классов или отсутствия ООП.
Безусловно, но тут больше обсуждается значимость наличия или отсутствия ограничений доступа. По крайней мере я не согласен конкретно с высказыванием:
Ограничения доступа — прежде всего в голове у программиста.
Я как раз считаю что программист не должен помнить контракты для своих классов и предугадывать для чужих, а для этого должны использоваться средства языка.
Это до особо эпического клиента, имхо. Когда понимаешь заранее что то что ты делаешь никому не нужно, и либо не будет использоваться, либо будет просто полностью выброшено и переписано (без предпосылок заранее, подключился новый заместитель руководителя поддепартамента департамента подразделения филиала организации и сказал что у них все по другому, и нужно все сделать абсолютно по другому), когда чтобы со стороны заказчика ответили на вопрос нужно сначала несколько дней подряд писать письма на которые не получишь ответа, а потом эскалировать до руководства, когда представители заказчика начинают спорить о том что строка «attachment_data» это валидное base64binary значение, когда постановка задач просто письмо с перепиской полусотни человек между собой без конкретного результата, когда тебя дергают звонками примерно раз в 20-30 минут, когда костыли уже перестаешь считать и даже не дергаешься переделать по нормальному, потому что на этой неделе надо успеть еще 20 никому не нужных задач… В общем накипело, наверно если бы я не любил программировать я бы не терял мотивацию в вышеописанных условиях.
Ну, как по мне наоборот расслабляет когда можешь рассчитывать на интерфейс модуля зная что вряд ли нарвешься на временную связность например при использовании его процедур и функций, или что все нужные зависимости у него установлены (либо будут получены во время вызова метода откуда нибудь) а также то что публичные методы писались хоть более менее в расчете на то что будут использоваться без понимания деталей их работы, тогда как при написании приватных можно сделать больше допущений о параметрах и вариантах поведения и дать абстракции немного «протечь»
По мне как раз возможность ограничения доступа на уровне языка важна, ведь по сути без ограничений доступа только по коду непонятно будет где интерфейс, а где реализация. Наличие и соблюдение контрактов важно тем что, имхо: 1) снижает сложность системы за счет вынесения в паблик только специально предназначенных для этого вещей; 2) без костылей в виде комментариев или памяти программиста с ходу позволяет использовать параметрический полиморфизм над объектами с одинаковым контрактом; 3) облегчает инструментальное взаимодействие с кодом и использование той же контекстной подсказки.
Не соглашусь, по крайней мере по моим наблюдениям раньше как раз видел только детали и «магию», а сейчас более широко могу видеть, поднимаясь на более высокие уровни абстракции.
, в случае знания концепций с использованием которых он был написан.
Мы у себя реализовывали подобный механизм для обмена с мобилкой (тоже на 1с через планы обмена). Методу ВыбратьИзменения можно передать массив содержащий только часть данных, а массив можно получить из таблиц изменений. Выглядит в результате это так себе, но работает.
Безусловно, но тут больше обсуждается значимость наличия или отсутствия ограничений доступа. По крайней мере я не согласен конкретно с высказыванием:
Я как раз считаю что программист не должен помнить контракты для своих классов и предугадывать для чужих, а для этого должны использоваться средства языка.