А если человек уехал в отпуск, а кошечку кормить должен добрый сосед (соседка), у которого никогда не было опыта? Все эти отсылки к реальному миру только затуманивают абстракции.
Человек, уехавший в отпуск, оставляет инструкцию соседке — и она использует её. Назовем это стратегией.
У человека есть набор стратегий по обработке объектов. Эти стратегии могут меняться. Этими стратегиями можно обмениваться, потому что они сделаны — вот сюрприз! — как чистые функции, не зависящие от текущего владельца стратегии. Им максимум приходит абстрактный объект с интерфейсом «контекст текущего пользователя», если нужно позаимствовать какие-то особенности текущего контекста.
Стратегии — это мощный паттерн, делайте их! Если язык поддерживает standalone-функции — их часто можно делать чистыми функциями.
Но повторюсь, вот такие рассуждения о человеке-кошке только затуманивают суть )
// хороший метод, состояние не модифицируется, но есть копирование
ну смотрите, у вас есть копирование. Причем картинки, тяжеловесного объекта. Вы всерьез считаете, что это всегда хорошо?
Во многих ситуациях — это плохо. Да, сложно работать с мутабельными объектами. Но жрать память, тратить беспечно ресурсы системы — не в каждом случае можно. В игровых движках за такую иммутабельность вам руки оторвут.
В программировании контроллеров — тоже.
Я к тому, что абстрактный спор — он оторван. Смотреть надо на целесообразность в конкретной реализации. Но лишнее копирование картинок — это даже на фронтенде не всегда хорошо.
отказываемся от метода в конструкторе — получаем дополнительный бойлеплейт при использовании объекта (когда отдельно надо вызвать конструктора, а затем его проинициализировать).
Вообще в Философии Java одного известного автора четко описано, почему возникла потребность в конструкторах — потому что огромное количество багов происходило (и происходит) при инициализации, то есть подготовке объекта к работе.
По этой идеологии, инициализацию следует как можно больше засовывать в конструктор. Отсюда возникает потребность в методах, декомпозирующих инициализацию, иначе мы получим простыню кода, если инициализация сложная.
Антипаттерном эти методы становятся только в том случае, если вы их делаете публичными.
Я кстати не в курсе, Мишко Хевери в списке Java-гуру сейчас котируется выше автора «Философии Java»? Если да, то конечно, надо его слушать.
На самом деле нет — надо решать самому. У каждого инженерного выбора есть плюсы и минусы. Как писал Мартин Фоулер, невозможно создать абсолютно чистую архитектуру, она всегда будет грязной, и в каком-то месте грязь будет чудовищной. Но инженер может и должен минимизировать её расползание по системе )
// циклическая зависимость является проблемой самой по себ
ну хоть кто-то это сказал )
В соседней области программирования, в фреймворках, о которых, вы вероятно даже слышали, при билде проекта сборщик по умолчанию ругается, если видит циклические зависимости (хотя и собирает).
Вспомнил 2016, когда я перепробовал разные архитектуры для Android, вздрогнул.
Потом вспомнил, как классно всё на JS-фронтенде, где я живу сейчас, порадовался. Потом подумал — а почему до сих пор на Андроиде живут, по сути, в парадигме контроллеров-вью, когда Redux-архитектура была бы намного удобнее, особенно учитывая тот факт, что на мобилках у нас вью постоянно умирает?
Погуглил немного и снова убедился, что я не самый умный человек на Земле и люди уже давно написали даже библиотечки, как под iOS, так и под Android. Ключевые слова
— ReKotlin (Android)
— ReSwift (iOS)
Ключевая особенность Redux-архитектуры — вся логика живет отдельно от вью. Не куча вью каждый со своими презентарами, а вообще отдельно. Есть абстрактный слой с общим состоянием приложения. Есть абстрактная логика обработки. View только подписываются и отписываются от состояния.
У Redux в его подробной нынешней формулировке есть вещи, с которыми я не согласен и о которых умолчу, но сама концепция, что всё состояние приложения хранится в одном месте, а логика живёт отдельно от View и по сути обрабатывает запросы на изменение состояния по паттерну Команда (что даёт заодно гибкие возможности по Undo/Redo) — она даёт намного, намного меньше кода, чем классический подход «1 экран — от 3 обязательных файлов и больше». Будет 1 экран — 1 файл (View), которое подписывается на логику.
Попробуйте, может понравиться. Я признаю, что сам еще не пробовал Redux в Android, некогда ) Но судя по появлению библиотек — люди уже пробуют и находят более мощным и удобным, чем классические MVP, MVVM и тд, и тп
Потому что в технологическом прогресс неизбежно настанет такой момент, когда мы сможем сказать персональному компьютеру — отсортируй мне фоточки по лицам. И он внезапно сам все выведет систему распознавания лиц. Хотя никто над этим специально не будет работать, просто будет очень мощная система.
Люди плохо выращиваются. Можно вбухать кучу денег без гарантий. В этом проблема даже у Штатов, которые в IT не могут воспроизвести достаточное количество специалистов — и когда Трамп начинает очередную бучу про мигрантов, IT-гиганты как один начинают заявлять, что без свободного перемещения людей — айти-индустрия обречена
самый совершенный поршневой авиадвигатель после 2 мировой войны содержал более 20 тысяч деталей и давал скорость 100 условных единиц. Первый реактивный двигатель того же времени содержал 900 деталей, и давал скорость 200 единиц. Опять смена сути технологии, а не повторение или оптимизация того, что есть.
Обоснуйте. Любое инженерное решение не является абсолютным и подразумевает контекст.
В некоторых контекстах — проще влепить nodeIntegration: true без всяких угроз безопасности. Это наше приложение, наш код, мы его контролируем. Если есть доступ чужого JS-скрипта, удаленной веб-страницы — ну это вопрос к вам, почему и зачем вы это допускает в Электроне. Тогда да, ставьте nodeIntegration: false и городите усложненную архитектуру с делегацией запросов.
Программисты — это инженеры, а не веруны в догмы. Любое утверждение должно иметь четко описанный контекст применения.
Проблема в том, как перевести процесс из лабораторных условий в производственные. Масштабируется ли он вообще? Какие усилия надо произвести, что обработать тонну реального шлака на каком-то складе? Что останется после обработки — химически/биологически нейтральные отходы или нечто, что надо будет хранить ещё дороже? И много, очень много таких вопросов.
Просто пример — каждый дома может экспериментировать с дрожжами и рассадой. Но чтобы получить из дрожжевых экспериментов что-то ценнее обычной бражки — надо вложиться серьезно, как и в случае рассады. Эта дельта и есть разница между лабораторным экспериментом, подтверждающим саму возможность, и индустриальным производством, выдающим постоянный продукт со стабильным качеством.
Я регулярно читаю про эксперименты с бактериями — да любой может прогуглить «бактерии отходы», «бактерии синтез топлива» — таких экспериментов очень много. Уранопоедающие бактерии, бактерии, разлагающие пластик… Куча новостей. Но где они в смысле реальных производств, реальной работы за пределами лабораторий? Пока индустриального применения увы не видно.
Хотя сама идея выглядит в потенциале очень красивой — сыпанул щепотку закваски и тебе пополз чистый металл (топливо, спирт, подписчики — нужное подчеркнуть).
Ну и количество экспериментов с бактериями всё-таки позволяет надеяться, что однажды промышленники заставят их работать )
// Надо учиться доверять ИИ
это хорошо как призыв, но плохо, как инструкция — непонятно, как учить, непонятно, как измерять результат, вообще нет гарантии, что люди будут учиться, а не подделывать метрики
в то же время другая задача — учить ИИ объяснять — выглядит хотя бы более решаемой и с более ясными метриками
Человек, уехавший в отпуск, оставляет инструкцию соседке — и она использует её. Назовем это стратегией.
У человека есть набор стратегий по обработке объектов. Эти стратегии могут меняться. Этими стратегиями можно обмениваться, потому что они сделаны — вот сюрприз! — как чистые функции, не зависящие от текущего владельца стратегии. Им максимум приходит абстрактный объект с интерфейсом «контекст текущего пользователя», если нужно позаимствовать какие-то особенности текущего контекста.
Стратегии — это мощный паттерн, делайте их! Если язык поддерживает standalone-функции — их часто можно делать чистыми функциями.
Но повторюсь, вот такие рассуждения о человеке-кошке только затуманивают суть )
Лабиринт абсолютно случайный. Стены разрушать нельзя. Но есть нюанс — стены со временем сдвигаются, образуя проходы или закрывая существующие.
Таким образом, в такой игре главное — сгенерировать персонажа не в одном тупике с монстром.
Пользуйтесь. Хотя кому сейчас нужен такой геймплей? Разве что в рогаликах )
PS:
ну смотрите, у вас есть копирование. Причем картинки, тяжеловесного объекта. Вы всерьез считаете, что это всегда хорошо?
Во многих ситуациях — это плохо. Да, сложно работать с мутабельными объектами. Но жрать память, тратить беспечно ресурсы системы — не в каждом случае можно. В игровых движках за такую иммутабельность вам руки оторвут.
В программировании контроллеров — тоже.
Я к тому, что абстрактный спор — он оторван. Смотреть надо на целесообразность в конкретной реализации. Но лишнее копирование картинок — это даже на фронтенде не всегда хорошо.
Статистика или личные впечатления?
Вообще в Философии Java одного известного автора четко описано, почему возникла потребность в конструкторах — потому что огромное количество багов происходило (и происходит) при инициализации, то есть подготовке объекта к работе.
По этой идеологии, инициализацию следует как можно больше засовывать в конструктор. Отсюда возникает потребность в методах, декомпозирующих инициализацию, иначе мы получим простыню кода, если инициализация сложная.
Антипаттерном эти методы становятся только в том случае, если вы их делаете публичными.
Я кстати не в курсе, Мишко Хевери в списке Java-гуру сейчас котируется выше автора «Философии Java»? Если да, то конечно, надо его слушать.
На самом деле нет — надо решать самому. У каждого инженерного выбора есть плюсы и минусы. Как писал Мартин Фоулер, невозможно создать абсолютно чистую архитектуру, она всегда будет грязной, и в каком-то месте грязь будет чудовищной. Но инженер может и должен минимизировать её расползание по системе )
ну хоть кто-то это сказал )
В соседней области программирования, в фреймворках, о которых, вы вероятно даже слышали, при билде проекта сборщик по умолчанию ругается, если видит циклические зависимости (хотя и собирает).
Это потенциальная проблема сама по себе
Потом вспомнил, как классно всё на JS-фронтенде, где я живу сейчас, порадовался. Потом подумал — а почему до сих пор на Андроиде живут, по сути, в парадигме контроллеров-вью, когда Redux-архитектура была бы намного удобнее, особенно учитывая тот факт, что на мобилках у нас вью постоянно умирает?
Погуглил немного и снова убедился, что я не самый умный человек на Земле и люди уже давно написали даже библиотечки, как под iOS, так и под Android. Ключевые слова
— ReKotlin (Android)
— ReSwift (iOS)
Ключевая особенность Redux-архитектуры — вся логика живет отдельно от вью. Не куча вью каждый со своими презентарами, а вообще отдельно. Есть абстрактный слой с общим состоянием приложения. Есть абстрактная логика обработки. View только подписываются и отписываются от состояния.
У Redux в его подробной нынешней формулировке есть вещи, с которыми я не согласен и о которых умолчу, но сама концепция, что всё состояние приложения хранится в одном месте, а логика живёт отдельно от View и по сути обрабатывает запросы на изменение состояния по паттерну Команда (что даёт заодно гибкие возможности по Undo/Redo) — она даёт намного, намного меньше кода, чем классический подход «1 экран — от 3 обязательных файлов и больше». Будет 1 экран — 1 файл (View), которое подписывается на логику.
Попробуйте, может понравиться. Я признаю, что сам еще не пробовал Redux в Android, некогда ) Но судя по появлению библиотек — люди уже пробуют и находят более мощным и удобным, чем классические MVP, MVVM и тд, и тп
Потому что в технологическом прогресс неизбежно настанет такой момент, когда мы сможем сказать персональному компьютеру — отсортируй мне фоточки по лицам. И он внезапно сам все выведет систему распознавания лиц. Хотя никто над этим специально не будет работать, просто будет очень мощная система.
спасибо, ясно, что будущие станки станут проще
в смысле, чем проще либа, тем лучше
// не делайте так.
Обоснуйте. Любое инженерное решение не является абсолютным и подразумевает контекст.
В некоторых контекстах — проще влепить nodeIntegration: true без всяких угроз безопасности. Это наше приложение, наш код, мы его контролируем. Если есть доступ чужого JS-скрипта, удаленной веб-страницы — ну это вопрос к вам, почему и зачем вы это допускает в Электроне. Тогда да, ставьте nodeIntegration: false и городите усложненную архитектуру с делегацией запросов.
Программисты — это инженеры, а не веруны в догмы. Любое утверждение должно иметь четко описанный контекст применения.
Это как подозревать студентов в том, что они специально учатся лишь для того, чтобы устроиться на работу
Но для мелкого текста и для быстрого чтения я предпочел бы Arial или Verdana (Roboto тоже устроит)
Просто пример — каждый дома может экспериментировать с дрожжами и рассадой. Но чтобы получить из дрожжевых экспериментов что-то ценнее обычной бражки — надо вложиться серьезно, как и в случае рассады. Эта дельта и есть разница между лабораторным экспериментом, подтверждающим саму возможность, и индустриальным производством, выдающим постоянный продукт со стабильным качеством.
Я регулярно читаю про эксперименты с бактериями — да любой может прогуглить «бактерии отходы», «бактерии синтез топлива» — таких экспериментов очень много. Уранопоедающие бактерии, бактерии, разлагающие пластик… Куча новостей. Но где они в смысле реальных производств, реальной работы за пределами лабораторий? Пока индустриального применения увы не видно.
Хотя сама идея выглядит в потенциале очень красивой — сыпанул щепотку закваски и тебе пополз чистый металл (топливо, спирт, подписчики — нужное подчеркнуть).
Ну и количество экспериментов с бактериями всё-таки позволяет надеяться, что однажды промышленники заставят их работать )
это хорошо как призыв, но плохо, как инструкция — непонятно, как учить, непонятно, как измерять результат, вообще нет гарантии, что люди будут учиться, а не подделывать метрики
в то же время другая задача — учить ИИ объяснять — выглядит хотя бы более решаемой и с более ясными метриками