интересно, как они понимают, работает оно или нет?

на глаз

естественно там тестов нет. Просто ручками все сверяют по отчетам, а там уж как повезет

мы так релизим

перекрестился и деплоишь по фтп )))))

а если упадет? Что тогда?

на все воля аллаха

У нас на проекте была такая кнопка - сами делали.

для чего?

Собирали проект. Это было 15+ лет назад, когда всякие модные CI ещё были на так чтобы mainstream.

Нажал на кнопку - скрипт вытянул сорцы из репозитория, запустил сборку. Баловство, конечно, но выглядело весело.

https://refactoring.guru/ru/design-patterns/flyweight вот понять не могу. Как рощу отрисовывать будет, если некоторые объекти фактически одни и те же. Дерево не сможет находиться в разных координатах. В чем прикол?

Паттера lightweight.

https://refactoring.guru/ru/design-patterns/flyweight вот понять не могу. Как рощу отрисовывать будет, если некоторые объекти фактически одни и те же. Дерево не сможет находиться в разных координатах. В чем прикол?

Почему не сможет, одинаковые деревья просто в разных местаз

Идея как раз в том, что различающаяся информация хранится в объекте, а одинаковая - в одном каком-то месте, и много объектов на неё ссылаются.

https://refactoring.guru/ru/design-patterns/flyweight вот понять не могу. Как рощу отрисовывать будет, если некоторые объекти фактически одни и те же. Дерево не сможет находиться в разных координатах. В чем прикол?

Например, рисуем дерево - нужна позиция, форма, текстура. По-тру-ООП мы эти данные должны бы инкапсулировать в один объект. Для рощи нужно 1000 деревьев - согласно тру-ООП у нас в памяти 1000 объектов, и 1000 одинаковых (!) текстур дерева в каждом. Суть lightweight - вынести одинаковые части объектов в один-единственный внешний объект. Мы в нашем примере могли бы хранить так одну на всех текстуру.

Идея как раз в том, что различающаяся информация хранится в объекте, а одинаковая - в одном каком-то месте, и много объектов на неё ссылаются.

кеширование - вид сбоку

кеширование - вид сбоку

С этим мне сложно согласиться.

С этим мне сложно согласиться.

Вот в java например Integer кешируются до 128 (если не ошибаюсь) по дефолту и везде в рантайме, где бы ты не использовал допустим целое число 8, то везде это будет ссылка на один и тот же обьект.

Кэширование по сути сохранение информации дольше, чем необходимо, с целью повышения скорости доступа к ней. Lightweight идейно про другое.

Вот в java например Integer кешируются до 128 (если не ошибаюсь) по дефолту и везде в рантайме, где бы ты не использовал допустим целое число 8, то везде это будет ссылка на один и тот же обьект.

В коде оно конечно похоже будет выглядеть, но цели преследует всё же разные.

В одном случае - усккорение доступа, в другом - экономия памяти.

К словм сказать, кэширование как раз НЕ экономит память обычно - скорее наоборот.

В коде оно конечно похоже будет выглядеть, но цели преследует всё же разные.

а чем это принципиально отличие чисел и деревьев?

а чем это принципиально отличие чисел и деревьев?

В различающихся целях.

Суть - есть много одинаковых сущностей, вместо использования 100 этих сущности мы будет использовать один экземпляр сущности, а везде где нужно будем на неё ссылаться.

да что ты не как джавист, памяти мало что-ли?

Это про lightweight. А пример про Integer - кэширование (заранее создать объекты, хранить их, не удаляя, чтобы когда попросят - быстро выдать их, без задержек на выделение памяти).

Хотя по реализации похоже, да.

Повторюсь, цели разные, а реализация похожая.

Это про lightweight. А пример про Integer - кэширование (заранее создать объекты, хранить их, не удаляя, чтобы когда попросят - быстро выдать их, без задержек на выделение памяти).

В общем всё нужно для экономии памяти или для ускорения доступа, ну или еще более общее - устранение дублирования.

да что ты не как джавист, памяти мало что-ли?

Памяти всегда мало) А если это преждевременная оптимизация то уже плохо.

С кэшем это не всегда устраненте дублирования - может быть несколько же кешей, где как раз дублирующиеся данные.

да что ты не как джавист, памяти мало что-ли?

Хотел было возразить "я не джавист, я плюсовик". Но внезапно вспомнил, что теперь-то я и правда джавист.

"Как рощу отрисовывать будет, если некоторые объекти фактически одни и те же. Дерево не сможет находиться в разных координатах. В чем прикол?" Выше писали вот это, я думаю что проблема как раз в том что дерево ещё и знает где оно находиться, сейчас нашел пример в книге Гранд "Шаблоны проэктирования на java" там пример с приложением текстовым редактором, где каждая буква это обьект, чтобы не создавать каждый раз к примеру новую букву А, создается только один экземпляр, а потом уже отдается ссылка на этот экземпляр (а это же чем то еще напоминает синглтон....) То же самое что и мой пример с Integer

Нет, всё таки там пример не совсем удачный, дерево не должно знать о своём расположении в лесу.

меня немного другое смущает. Допустим у нас 3 породы деревьев. Нужно нарисовать 30 деревьев, отличаются только по высоте. Каждой породы по 10 штук. Как я одним объектом в один момент времени отображу 10 деревьев одной породы в один момент времени?

Это коллекция объектов будет

В которой есть метод отобразить

меня немного другое смущает. Допустим у нас 3 породы деревьев. Нужно нарисовать 30 деревьев, отличаются только по высоте. Каждой породы по 10 штук. Как я одним объектом в один момент времени отображу 10 деревьев одной породы в один момент времени?

Тут стоит отталкиваться от проблемы, которую решает паттерн. В случае lightweight - "проблема: много дублирующихся данных; решение: одинаковые данные пусть хранятся отдельно, и используются многими объектами." Соответствено если в твоём примеое проблемы с хранением одинаковых данных нет - то и паттерн Lightweight неприменим.

видимо пример неудачный

меня немного другое смущает. Допустим у нас 3 породы деревьев. Нужно нарисовать 30 деревьев, отличаются только по высоте. Каждой породы по 10 штук. Как я одним объектом в один момент времени отображу 10 деревьев одной породы в один момент времени?

допустим у тебя будет какой то класс фабрика по созданию деревьев, у тебя будет метод, в котором ты будешь указывать породу и параметры, допустим ты создаешь "берёза, высота 10м" в фабрике создасться этот обьект, и добавиться в внутреннюю коллекцию деревьев, и тебе будет отдана ссылка на этот обьект, потом ты создашь "берёза 11м" всё повториться, но когда ты создаешь ещё один обьект "берёза 10м" то тебе будет отдана ссылка на экземпляр уже существующего обьекта.

меня немного другое смущает. Допустим у нас 3 породы деревьев. Нужно нарисовать 30 деревьев, отличаются только по высоте. Каждой породы по 10 штук. Как я одним объектом в один момент времени отображу 10 деревьев одной породы в один момент времени?

Давай порассуждаем - какие данные у твоих объектов будут одинаковые, а какие - разные?

породы одинаковые, высота будет отличаться

а может и не отличаться, там уж как повезет

а может и не отличаться, там уж как повезет

Ну тут важно отталкиваться от конкретной проблемы. Если "признаков нет" - паттерн просто не применим.

а может и не отличаться, там уж как повезет

Если говорить с практической точки зрения - в играх первый кандидат на lightweight будет текстура, шейдер для дерева, так как обычно для всех деревьев стараются использовать одну и ту же текстуру "кора дерева", например.

я похоже зря заострил внимание на позиционировании деревьев. Несколько одинаковых деревьев в одной точке не будет нарисовано, т.к. это не имеет смысла. В итоге выигрыш, расход памяти меньше

в общем я понял. Чем-то составной ключ напоминает

Да, по сути так и есть - вместо хранения всего в одной "записи" ты хранишь часть данных отдельно, "в другой таблице", и несколько "записей" на них могут туда ссылаться.

И логика в общем очень сильно похожая - избегаем дублирования.

у на стут было обсуждение что такое архитекктура. вот наткнулся на определение

Software architecture is the structure that defines the flow of information through a software system. It is a set of decisions made about how software is organized and operates in order to meet the goals of that software.

Architecture is simply a set of attributes about how your code is laid out, organized, and how it interacts with other pieces or layers of the code.

у на стут было обсуждение что такое архитекктура. вот наткнулся на определение

и все же определение "архитектура это набор ограничений налагаемых на систему для достижения определенных характеристик оной" мне нравится больше.

оно... менее двусмысленное

ну и в целом очень похоже на то что ты привел

И логика в общем очень сильно похожая - избегаем дублирования.

когда избегаем дублирования стоит учитывать откуда приходят изменений. То есть не стоит устранять дублирование, даже если код выглядит 1 в 1, если у этих штук разные потоки изменений. У меня пример был - новости. Есть новости пользователей (определенной группы) и есть новости администрации. И то и то - просто новости пользователей. И разработчик который это пилил просто сделал это одной штукой. А потом через пару недель пришли изменения - для пользователей нужна премодерация, а для администраторов нужен чуть-чуть другой флоу публикации.

в итоге разработчик попытался решить все кастылями, через 2 дня попыток пришлось просто переписать модуль

ERROR: S client not available

когда избегаем дублирования стоит учитывать откуда приходят изменений. То есть не стоит устранять дублирование, даже если код выглядит 1 в 1, если у этих штук разные потоки изменений. У меня пример был - новости. Есть новости пользователей (определенной группы) и есть новости администрации. И то и то - просто новости пользователей. И разработчик который это пилил просто сделал это одной штукой. А потом через пару недель пришли изменения - для пользователей нужна премодерация, а для администраторов нужен чуть-чуть другой флоу публикации.

viva SRP

когда избегаем дублирования стоит учитывать откуда приходят изменений. То есть не стоит устранять дублирование, даже если код выглядит 1 в 1, если у этих штук разные потоки изменений. У меня пример был - новости. Есть новости пользователей (определенной группы) и есть новости администрации. И то и то - просто новости пользователей. И разработчик который это пилил просто сделал это одной штукой. А потом через пару недель пришли изменения - для пользователей нужна премодерация, а для администраторов нужен чуть-чуть другой флоу публикации.

В целом я и не лютую за не-дублирование данных - тут вопрос был про паттерн lightweight, и когда он применим (а когда - нет).

http://blog.cleancoder.com/uncle-bob/2017/05/05/TestDefinitions.html

Классификация тестов (еще одна, теперь банановая)

У кого опыт с event sourcing. Как вы делаете версионирование событий? Вариант который предлагают многие: Создать новый класс ивента с меткой V2 в имени класса, а старый отметить как Deprecated. class AccountCreated => AccountCreated_V2 Но такое чувство, как будто костыль какой-то. Может есть более изящный способ, с преобразованием старых ивентов в новые, прозрачно для системы?

тут несколько вопросов: 1. в чем их разница 2. что делать со старыми

У кого опыт с event sourcing. Как вы делаете версионирование событий? Вариант который предлагают многие: Создать новый класс ивента с меткой V2 в имени класса, а старый отметить как Deprecated. class AccountCreated => AccountCreated_V2 Но такое чувство, как будто костыль какой-то. Может есть более изящный способ, с преобразованием старых ивентов в новые, прозрачно для системы?

самый простой способ версионировать вещи - не версионировать

> class AccountCreated => AccountCreated_V2 а чем они отличаются?

я знаю про практику когда просто добавляются небольшие специализированные ивенты или же они просто дублируются. А если ты говоришь про то что уже хранится в базе - есть варианты как это хэндлить но все сильно к конкретному кейсу привязано

https://www.youtube.com/watch?v=PJjHfa5yxlU

Доброе утро, какую архитектуру сейчас круто использовать, при проектирование андроид приложений?

Mvc, mvp, mvvm

Mvc, mvp, mvvm

2.

А нумерация начинается с нуля или 1?))

Mvc, mvp, mvvm

чаще юзают mvp, можно попробовать силы с mvvm, ну а далее зависит от того что ты делаешь

есть же еще вэйперы всякие, которые перед использованием нужно хорошенько изучить и понять зачем

Ну задача моя, есть у меня активити на котором 10 фрагментов будет

Если использовать, mvp то мне нужно для каждого фрагмента модельку и презентер делать?

Есть ещё вроде mvp clean architecture

Где соблюдается солид

Правда ещё не разобрался

)

Если использовать, mvp то мне нужно для каждого фрагмента модельку и презентер делать?

презентер - да, модельку - it depends.

в целом смотря как ты будешь делать, есть варианты при которых "моделькой" будет тупо структура данных проброшенная из сервисного слоя

Есть ещё вроде mvp clean architecture

которую я тебе рекомендую использовать ТОЛЬКО если ты понимаешь почему она clean (по сути Дядя боб не для Андроида clean architecture пушил)

Где соблюдается солид

SOLID и в обычном MVP соблюдается если ты его не нарушаешь

http://unpetitaccident.com/pub/compeng/languages/JAVA/Principles_and_Patterns.pdf

почитай для начала