Ответственность должна быть на объекте (принцип инкапсуляции)
А если на объекте лежит и непосредственная ответственность, кроме хранения данных, для чего его класс и создавали, то... похоже, страдает принцип единственной ответственности...
Основным шаблоном проектирования является "Стратегия" как способ присвоить чему-то значение в виде исполняемого кода с известным контрактом вызова -- способ облечь функциональное программирование в одежды объектно-ориентиованного. В JVM-языках реализуется через понятие интерфейса.
К удивлению для статьи с таким названием, обнаружил в ней нечто полезное: объяснение разницы между фабричным методом и абстрактной фабрикой с разъяснением зачем нужна фабрика фабрик.
Стоит один раз менеджменту увидеть время, потраченное всей командой на звонки и умножить на почасовую ставку, и выводы делаются сами собой.
Были прецеденты или вы это умозрительно говорите? Могут сделать и другие выводы: не успеваешь -- твои проблемы, значит ты такой плохой разработчик, что с тобой нельзя без совещаний, оставайся доделывай после работы, задания с тебя никто не снимал.
Промпт не промпт, но в "человеческом" мире меня с некоторых пор начала забавлять ситуация, когда ТЗ по объёму превосходит сделанный на основе него код. Поэтому, мне кажется, в реальной жизни "качественные ТЗ" и встречаются настолько редко, что все о них слышали, но мало кто видел.
А не надо поддерживать, по изначальному замыслу. Просто уточняете "заклинание". "Поддерживать" теперь надо промпт, а не сгенерированный по нему код, код уходит на уровень, на котором раньше был байт-код.
Писал я на этом ассемблере 30+ лет назад, INCB занимает два байта, а BISB -- три или четыре (забыл как там с выравниванием по чётности, скорее всего таки четыре): там есть ещё аргумент -- битовая маска. Чел сэкономил программную память, судя по применению однобайтовой переменной для флага, это было актуально...
Если во время собеседований не удается выдавить ни слова, и голова пустая, что даже своими словами не объяснить, можно попросить продемонстрировать на практике.
Мне кажется, я нашёл ключевой ответ: потому что они увеличивают связность кода. Этим ответом покрывается и конкретизируется также предыдущий мой ответ. В случае гигантской монолитной (как ныне модно выражаться) библиотеки это нужно, в случае много-микро-модульной системы это создаёт лишние зависимости между модулями.
Если глобально и коротко, то потому, что подход к разработке встроенной стандартной библиотеки Java и подход к разработке прикладной коммерческой программы - разные
Дополнительная причина - что синтаксис языка Java вынуждает писать много boilerplate-кода вокруг исключений. Тут и предыдущий абзац "в строку", потому что именно в стандартной библиотеке такое терпимо и даже, по соображениям надёжности, потребно, а в прикладной программе в основном засоряет код, закапывая "основной путь" в глубине обработчиков исключений.
А если на объекте лежит и непосредственная ответственность, кроме хранения данных, для чего его класс и создавали, то... похоже, страдает принцип единственной ответственности...
Основным шаблоном проектирования является "Стратегия" как способ присвоить чему-то значение в виде исполняемого кода с известным контрактом вызова -- способ облечь функциональное программирование в одежды объектно-ориентиованного. В JVM-языках реализуется через понятие интерфейса.
К удивлению для статьи с таким названием, обнаружил в ней нечто полезное: объяснение разницы между фабричным методом и абстрактной фабрикой с разъяснением зачем нужна фабрика фабрик.
"...здорового человека"
С телешоппингом и телебанкингом. Но без отвлекающих факторов в виде лишней мультимедии.
И тут уместно напомнить про Minitel...
Особенно когда в анамнезе имеется ковид с реанимацией, от которого страдают внимание и память. Крадут последние остатки внимания.
Были прецеденты или вы это умозрительно говорите? Могут сделать и другие выводы: не успеваешь -- твои проблемы, значит ты такой плохой разработчик, что с тобой нельзя без совещаний, оставайся доделывай после работы, задания с тебя никто не снимал.
Промпт не промпт, но в "человеческом" мире меня с некоторых пор начала забавлять ситуация, когда ТЗ по объёму превосходит сделанный на основе него код. Поэтому, мне кажется, в реальной жизни "качественные ТЗ" и встречаются настолько редко, что все о них слышали, но мало кто видел.
А не надо поддерживать, по изначальному замыслу. Просто уточняете "заклинание". "Поддерживать" теперь надо промпт, а не сгенерированный по нему код, код уходит на уровень, на котором раньше был байт-код.
По крайней мере это так задумано.
И те и те.
Для гироскутера нужна поверхность без уклонов, это редкость.
По-моему, это у любых аккумуляторов так.
Как раз try/catch несколько мешает. Нельзя просто так взять и выделить в функцию блок, кидающий исключения, их нужно либо объявить либо обработать.
Есть подозрение, что первую версию оборудования, под которую писался софт, просто отключали чаще чем раз в 256 использований.
Писал я на этом ассемблере 30+ лет назад,
INCBзанимает два байта, аBISB-- три или четыре (забыл как там с выравниванием по чётности, скорее всего таки четыре): там есть ещё аргумент -- битовая маска. Чел сэкономил программную память, судя по применению однобайтовой переменной для флага, это было актуально...Читал, ждал, когда у людей с такими замашками дела пойдут плохо. И таки пошли...
На практику времени не дают...
Мне кажется, я нашёл ключевой ответ: потому что они увеличивают связность кода. Этим ответом покрывается и конкретизируется также предыдущий мой ответ. В случае гигантской монолитной (как ныне модно выражаться) библиотеки это нужно, в случае много-микро-модульной системы это создаёт лишние зависимости между модулями.
Если глобально и коротко, то потому, что подход к разработке встроенной стандартной библиотеки Java и подход к разработке прикладной коммерческой программы - разные
Дополнительная причина - что синтаксис языка Java вынуждает писать много boilerplate-кода вокруг исключений. Тут и предыдущий абзац "в строку", потому что именно в стандартной библиотеке такое терпимо и даже, по соображениям надёжности, потребно, а в прикладной программе в основном засоряет код, закапывая "основной путь" в глубине обработчиков исключений.