Когда джентльмены проигрывают в игре, джентльмены меняют правила.
А если серьезно, в США закон имеет обратную силу? Непонятно, что он такого сделал, чего не делали другие? Так-то, он боролся со спуфингом. Или зарабатывать могут только обитатели Уолл-стрита, а обитатели Лондона имеют право только проигрывать? И он подданный королевы, на каком основании его американское "правосудие" взяло? Грустная история, конечно.
Насколько я понимаю, канареечные релизы можно применять для фич типа интерфейса или вывода какой-то информации. Но как можно выкатывать изменения в бизнес-логике для части пользователей? У одних пользователей счета формируются одним образом, а у других - по-другому? А они не бегают с изумленными воплями, почему у одних система работает одним образом, а у других - по-другому?
Бистро погуглил. Честно говоря, не понял, в чем проблема. У лазеров есть программа управления? Думаю есть. Рисуете рисунок в Компасе, сохраняете в в dwg, загружаете штатной прогой лазера и режете.
Насколько я понял, основная фича lightburn - это редактирование рисунка и управление лазером. Рисунок рисуете в Компасе, лазером управляете из проги в комплекте лазера.
Не спец, хотелось бы узнать - есть аналогичный функционал у "Компас" (у плагинов для него) или его аналогов? Что это вообще за тема? Насколько сложно написать плагин для Компаса, чтобы рисунок в команды для лазеркаттера (это ведь софт для лазеркаттера?) переводил?
В том, что в большом проекте эти наследования приводят к ООП-HELL. Огромное количество наследников, разобраться в их взаимосвязи и что откуда вызывается и какой путь выполнения - становится совершенно невозможно.
SOLID негативно относится к наследованию, и я этим совершенно согласен.
Выделение общего функционала следует делать не через выделение в parent, а через выделение в отдельный класс со своим интерфейсом. Spring этим и занимается.
Добавление функционала следует не через добавление наследника, а через композицию - выделение функционала в отдельный класс и либо иньекцией в наш класс, который будет это использовать, либо (что лучше, но надо смотреть), в окружение, которое вызывает наш класс и будет следом вызывать класс с дополнительным функционалом. Этим тоже занимается Spring.
На каждую новую фичу jar не будет, но новый class-файл - да, будет.
Все верно. Если надо добавить функционал в модуль, то мы текущий модуль не меняем, но делаем новый модуль, куда реализуем расширение, а переключение должно осуществляться в вызываемой программе. То есть, это не модуль должен знать, куда ему к примеру, выводить информацию, какая структура окружающего кода, а вызываемая система знает, какой интерфейс у исходного модуля и какой новый модуль нужно написать для расширенного функционала.
Текущие модули мы не меняем, а для нового функционала пишем новые модули.
Пример. Есть система. Есть модуль, который делает расчет. Расчет возвращается в окружающую его систему. Понадобилось, чтобы расчет форматировался определенным образом.
По старому и неправильному: мы меняем модуль расчета, добавляем код, который будет форматировать результаты. При этом этот модуль расчета должен будет знать детали реализации подсистемы вывода, необходимые форматы и кучу всего прочего.
Правильно: мы пишем новый модуль, который будет заниматься форматированием. Может, даже несколько модулей с одним и тем-же интерфейсом, но для html, json и так далее. Проводим в окружающей системе изменения для вызова форматирования результатов после выполнения расчета.
Если нужно расширить, чтобы система делала кроме расчета А еще и расчет Б, мы не меняем модуль с расчетом (который был только А, а мы даже не подозревали, что будет еще Б), а делаем еще один модуль с расчетом Б, а в вызывающей системе делаем switch и вызов (ну или применяем ООП).
SOLID (сокр. от англ.single responsibility, open–closed, Liskov substitution, interface segregation и dependency inversion) в программировании — мнемоническийакроним, введённый Майклом Фэзерсом (Michael Feathers) для первых пяти принципов, названных Робертом Мартином[1][2] в начале 2000-х[3], которые означали 5 основных принципов объектно-ориентированных проектирования и программирования.
У меня в школе всегда были пятерки за сочинения. Пишу я правильно. Но хоть убей, не понимаю, что такое причастие, деепричастие, страдательный залог и прочая ересь. мне в школе четверки ставили чисто из жалости, чтобы не портить аттестат. Учителя прекрасно понимали ценность знания этих "причастий". Чтобы писать правильно и говорить, надо знать свой язык (с частности, русский), а не эти слова, придуманные розенштейнами.
SOLID - это формализованные непонятно кем идеи Дяди Боба. Формализованные и превращенные в догмы, криво и (имхо) неправильно.
Я лично не мог понять их смысл, душа противилась. Потом я прочитал книги Дяди Боба и мне все стало понятно. В том смысле, что стало понятно, что имел в виду Дядя Боб.
Не надо изучать SOLID. Читайте Дядю Боба. У него все понятно, логично, красиво и правильно. В частности, только после его книг мне стал понятен смысл и сила Spring.
У меня в практике - постоянно. Не знаю, как в других шарагах, может, большинство вообще без проектов работают и пишут стопроцентрую отсебятину, но я сомневаюсь, что в Яндексе или Сбере пишут без проекта. Особенно в банковской сфере.
Я не согласен с автором, что программисты создают очень некрасивые и "запутанные" условия в if.
На самом деле, такие условия могут быть описаны в проекте и диктоваться бизнесом. И (я считаю), разработчик должен реализовать такие условия (ОСОБЕННО условия) один-в-один, как проекте.
Потому что, когда появится необходимость продебажить ошибки, последующие разработчики будут, имея на руках проект, мучительно сравнивать условия в проекте и в коде, "декомпилируя" ваши "оптимизированные" условия и сравнивая с условиями в проекте, в попытках выяснить, почему же код аффтара выполняет процессы не тем образом, как прописано в проекте, при правильно настроенных примерах-кейсах.
Имхо: код должен однозначно соответствовать по логике проекту и требованиям бизнеса. Особенно условия.
Второе возражение на isDisabled. isDisableb поле может определяться из поля базы какой-то таблицы. Таблица и поля диктуются логикой бизнеса, то есть, ты не можешь переименовать по своему хотению имена полей. Соответственно, и поле класса ты обязан называть isDisabled. И даже делать костыль-метод isEnabled ты не имеешь права. По причине того, что последующие разрабы при дебаге, при попытке выяснить, где используется поле isDisabled, не смогут его найти и будут долго распутывать ваши "упрощения" и "оптимизации".
ПС. Возможно, это же относится к сохранению в базу объектов в начале и выборке из базы в конце метода. Потому что, согласно требованию бизнеса, применяется уже имеющаяся хранимая процедура или триггер, где-то в середине. А вы такой умный, убрали "ненужное", и все приложение развалилось, причем не у вас на дебаге, и даже не при тестировании, а в продакшене через полгода, потому что эта процедура или триггер срабатывает в одном проценте случаев всех расчетов.
Возможно, потому что от программистов требуется, чтобы код (особенно такие условия) однозначно соответствовал проекту. В проекту вот такие условия, диктуемые бизнесом. Поэтому и программист реализует их в коде именно таким образом.
И я лично считаю, что это правильно. Потому что потом при дебаге, ревью кода или дополнениях, имея на руках проект модуля и имея соответствующий код, перекомпилировать ваше "оптимизированное" выражение и сравнивать его с выражением, описанным в проекте - занимает массу времени и сил, или как пишет автор, создает когнитивные сложности.
Кстати, почему автор не написал эту ловушку, очень часто присутствующую на практике, я не понимаю. "Реализуй код, максимально не совпадающим с описанием в проекте. Пусть условные выражения делают то, что требуется в проекте, но максимально отличным от проекта. Оптимизируй все, что можно. Пусть последующие разработчики при дебаге, имея проект на руках, сравнивали твой код и условия в проекте максимально долго и мучительно. Такую бомбу ревьюверы никогда не видят и не могут увидеть, потому что никто не сравнивает код с проектом, а даже если бы и увидели, то всегда можно сказать, что ты оптимизировал выражение и упростил код."
Случайности не случайны. В нашем мире жестко прописан закон сохранения энергии. Энергия не может случайно появиться. Все, все абсолютно - только преобразование энергии. А тут хлобысь - и вдруг ниоткуда появилось энергии в таком количестве, что хватает на формирование всего, что есть в нашей вселенной - мириады и мириады галактик и скоплений галактик.
Вот почему так-же нет в Java?! Один файл подправил - две трети файлов в проекте перекомпилируются.
Я не смог решить задачу про кошельки.
Когда джентльмены проигрывают в игре, джентльмены меняют правила.
А если серьезно, в США закон имеет обратную силу? Непонятно, что он такого сделал, чего не делали другие? Так-то, он боролся со спуфингом. Или зарабатывать могут только обитатели Уолл-стрита, а обитатели Лондона имеют право только проигрывать? И он подданный королевы, на каком основании его американское "правосудие" взяло? Грустная история, конечно.
Насколько я понимаю, канареечные релизы можно применять для фич типа интерфейса или вывода какой-то информации. Но как можно выкатывать изменения в бизнес-логике для части пользователей? У одних пользователей счета формируются одним образом, а у других - по-другому? А они не бегают с изумленными воплями, почему у одних система работает одним образом, а у других - по-другому?
Единственный кейс, как я вижу, где это можно использовать - в окнах автомобилей и истребителей. Во всяких приборах и прицелах.
Но явно не телевизоры.
Бистро погуглил. Честно говоря, не понял, в чем проблема. У лазеров есть программа управления? Думаю есть. Рисуете рисунок в Компасе, сохраняете в в dwg, загружаете штатной прогой лазера и режете.
Насколько я понял, основная фича lightburn - это редактирование рисунка и управление лазером. Рисунок рисуете в Компасе, лазером управляете из проги в комплекте лазера.
Не спец, хотелось бы узнать - есть аналогичный функционал у "Компас" (у плагинов для него) или его аналогов? Что это вообще за тема? Насколько сложно написать плагин для Компаса, чтобы рисунок в команды для лазеркаттера (это ведь софт для лазеркаттера?) переводил?
Простите, что?!! Вы отсылали свои генетические данные каким-то сайтам за рубеж? Это не запрещено у нас?
В том, что в большом проекте эти наследования приводят к ООП-HELL. Огромное количество наследников, разобраться в их взаимосвязи и что откуда вызывается и какой путь выполнения - становится совершенно невозможно.
SOLID негативно относится к наследованию, и я этим совершенно согласен.
Выделение общего функционала следует делать не через выделение в parent, а через выделение в отдельный класс со своим интерфейсом. Spring этим и занимается.
Добавление функционала следует не через добавление наследника, а через композицию - выделение функционала в отдельный класс и либо иньекцией в наш класс, который будет это использовать, либо (что лучше, но надо смотреть), в окружение, которое вызывает наш класс и будет следом вызывать класс с дополнительным функционалом. Этим тоже занимается Spring.
На каждую новую фичу jar не будет, но новый class-файл - да, будет.
Без понятия. Интуиция, взращенная чтением классической русской литературы.
Спасибо большое, обязательно почитаю!
Все верно. Если надо добавить функционал в модуль, то мы текущий модуль не меняем, но делаем новый модуль, куда реализуем расширение, а переключение должно осуществляться в вызываемой программе. То есть, это не модуль должен знать, куда ему к примеру, выводить информацию, какая структура окружающего кода, а вызываемая система знает, какой интерфейс у исходного модуля и какой новый модуль нужно написать для расширенного функционала.
Текущие модули мы не меняем, а для нового функционала пишем новые модули.
Пример. Есть система. Есть модуль, который делает расчет. Расчет возвращается в окружающую его систему. Понадобилось, чтобы расчет форматировался определенным образом.
По старому и неправильному: мы меняем модуль расчета, добавляем код, который будет форматировать результаты. При этом этот модуль расчета должен будет знать детали реализации подсистемы вывода, необходимые форматы и кучу всего прочего.
Правильно: мы пишем новый модуль, который будет заниматься форматированием. Может, даже несколько модулей с одним и тем-же интерфейсом, но для html, json и так далее. Проводим в окружающей системе изменения для вызова форматирования результатов после выполнения расчета.
Если нужно расширить, чтобы система делала кроме расчета А еще и расчет Б, мы не меняем модуль с расчетом (который был только А, а мы даже не подозревали, что будет еще Б), а делаем еще один модуль с расчетом Б, а в вызывающей системе делаем switch и вызов (ну или применяем ООП).
Это цитата из Вики.
У меня в школе всегда были пятерки за сочинения. Пишу я правильно. Но хоть убей, не понимаю, что такое причастие, деепричастие, страдательный залог и прочая ересь. мне в школе четверки ставили чисто из жалости, чтобы не портить аттестат. Учителя прекрасно понимали ценность знания этих "причастий". Чтобы писать правильно и говорить, надо знать свой язык (с частности, русский), а не эти слова, придуманные розенштейнами.
SOLID - это формализованные непонятно кем идеи Дяди Боба. Формализованные и превращенные в догмы, криво и (имхо) неправильно.
Я лично не мог понять их смысл, душа противилась. Потом я прочитал книги Дяди Боба и мне все стало понятно. В том смысле, что стало понятно, что имел в виду Дядя Боб.
Не надо изучать SOLID. Читайте Дядю Боба. У него все понятно, логично, красиво и правильно. В частности, только после его книг мне стал понятен смысл и сила Spring.
У меня в практике - постоянно. Не знаю, как в других шарагах, может, большинство вообще без проектов работают и пишут стопроцентрую отсебятину, но я сомневаюсь, что в Яндексе или Сбере пишут без проекта. Особенно в банковской сфере.
Я не согласен с автором, что программисты создают очень некрасивые и "запутанные" условия в if.
На самом деле, такие условия могут быть описаны в проекте и диктоваться бизнесом. И (я считаю), разработчик должен реализовать такие условия (ОСОБЕННО условия) один-в-один, как проекте.
Потому что, когда появится необходимость продебажить ошибки, последующие разработчики будут, имея на руках проект, мучительно сравнивать условия в проекте и в коде, "декомпилируя" ваши "оптимизированные" условия и сравнивая с условиями в проекте, в попытках выяснить, почему же код аффтара выполняет процессы не тем образом, как прописано в проекте, при правильно настроенных примерах-кейсах.
Имхо: код должен однозначно соответствовать по логике проекту и требованиям бизнеса. Особенно условия.
Второе возражение на isDisabled. isDisableb поле может определяться из поля базы какой-то таблицы. Таблица и поля диктуются логикой бизнеса, то есть, ты не можешь переименовать по своему хотению имена полей. Соответственно, и поле класса ты обязан называть isDisabled. И даже делать костыль-метод isEnabled ты не имеешь права. По причине того, что последующие разрабы при дебаге, при попытке выяснить, где используется поле isDisabled, не смогут его найти и будут долго распутывать ваши "упрощения" и "оптимизации".
ПС. Возможно, это же относится к сохранению в базу объектов в начале и выборке из базы в конце метода. Потому что, согласно требованию бизнеса, применяется уже имеющаяся хранимая процедура или триггер, где-то в середине. А вы такой умный, убрали "ненужное", и все приложение развалилось, причем не у вас на дебаге, и даже не при тестировании, а в продакшене через полгода, потому что эта процедура или триггер срабатывает в одном проценте случаев всех расчетов.
Возможно, потому что от программистов требуется, чтобы код (особенно такие условия) однозначно соответствовал проекту. В проекту вот такие условия, диктуемые бизнесом. Поэтому и программист реализует их в коде именно таким образом.
И я лично считаю, что это правильно. Потому что потом при дебаге, ревью кода или дополнениях, имея на руках проект модуля и имея соответствующий код, перекомпилировать ваше "оптимизированное" выражение и сравнивать его с выражением, описанным в проекте - занимает массу времени и сил, или как пишет автор, создает когнитивные сложности.
Кстати, почему автор не написал эту ловушку, очень часто присутствующую на практике, я не понимаю. "Реализуй код, максимально не совпадающим с описанием в проекте. Пусть условные выражения делают то, что требуется в проекте, но максимально отличным от проекта. Оптимизируй все, что можно. Пусть последующие разработчики при дебаге, имея проект на руках, сравнивали твой код и условия в проекте максимально долго и мучительно. Такую бомбу ревьюверы никогда не видят и не могут увидеть, потому что никто не сравнивает код с проектом, а даже если бы и увидели, то всегда можно сказать, что ты оптимизировал выражение и упростил код."
Возможно, я пропустил, но не вижу уникального индекса
balance_id, ref_id на таблице _balance_amountСлучайности не случайны. В нашем мире жестко прописан закон сохранения энергии. Энергия не может случайно появиться. Все, все абсолютно - только преобразование энергии. А тут хлобысь - и вдруг ниоткуда появилось энергии в таком количестве, что хватает на формирование всего, что есть в нашей вселенной - мириады и мириады галактик и скоплений галактик.