• Когда выделяется память для переменных внутри функциях?

    K0TlK
    @K0TlK
    Просто создай структуру, которая будет описывать движение и передавай ее. Если ты не создаешь инстансы референс типов, то память будет аллоцироваться на стеке, это просто пшик.

    Время, просранное на кэш мисс для получения данных монобеха будет больше, чем время, затраченное на этот иф. Нечего тут избегать.
    Написано
  • Почему рекомендуется использовать private а не просто ставить везде Public?

    K0TlK
    @K0TlK
    Василий Банников, соболезную. В юнити всю эту дичь тоже пытаются перетащить и di контейнеры каждый день новые, и скриптабле обжекты используют как дто, делают это те люди, которые ни одной игры в своей жизни не сделали и не понимают специфику создания приложений, работающих в реальном времени. Рекордов в юнитевской версии шарпа, к счастью, нет, а иммутабельность = 20 секунд фреймтайма, так что, надеюсь хоть этого избежать можно.
    Написано
  • Почему рекомендуется использовать private а не просто ставить везде Public?

    K0TlK
    @K0TlK
    Василий Банников,
    ситуация слишком простая, чтобы подход себя оправдал.

    Других ситуаций в подобных книгах и не показывают. Показывают только то, что можно расписать на 10 книг, налить воды и продать хомякам. Как пример, тот же принцип единой ответственности, три книги мартина, три разных определения, а принцип как был убогим, бесполезным, вырожденным куском субстанции, так и остался.

    После этого мне начинает казаться, будто мы говорим об одном и том же, но разными словами.

    Я говорю о том, что должна быть причина сделать поле приватным, ты говоришь о том, что должна быть причина сделать поле публичным. Это немножко противоположные вещи. Пользу своей версии я написал уже как минимум дважды: приватные поля становятся исключением из правил, их меньше => с первого взгляда становится видно, что поля приватные не просто так и трогать их, не разбираясь как все работает, не стоит => ценность приватных полей возрастает.
    Еще один пример рационального использования приватных полей - дверь с комплексной механикой открытия-закрытия. Будет несколько приватных полей, которые отвечают за то под каким углом дверь открыта в данный момент, какой угол был в предыдущем фрейме и т.д. Будут методы открыть/закрыть и свойство без сеттера/метод, который возвращает состояние двери в данный момент (открыта / открыта частично - открывается / открыта частично - закрывается / закрыта), основываясь на данных из этих приватных полей. Поля по типу материала двери, скорости ее открытия / закрытия, айди сущности, которая трогала дверь последний раз и т.д., будут публичными, потому что они никаким образом сломать важную логику открытия/закрытия двери не могут.
    Написано
  • Почему рекомендуется использовать private а не просто ставить везде Public?

    K0TlK
    @K0TlK
    Василий Банников,
    чистая архитектура у меня есть, но что-то я не помню там рекомендаций накидывать повсюду мелкие классы.

    Открой главу, которая называется "Принцип единой ответственности" и посмотри что он советует делать в конце главы. Мне даже не пришлось ничего искать, по оглавлению понятно на какой странице будет бред.

    Я тебя так понял, будто мы должны по-умолчанию делать все поля публичными и переводить их в приватные, если поняли, что они должны быть приватными.

    Нет, я этого нигде не писал. Изначально нужно понимать, когда поле должно быть приватным. Этих ситуаций минимум и они всегда видны изначально. Как это понять и пример, я писал выше. Очередное смотрю в книгу - вижу фигу.

    А дальше разработчика порвало, несите нового.

    Аргументация уровня дошкольника.

    Если обратить внимание, лично я ни разу не аппелтровал к защите и безопасности, ни в комментах, ни в ответах.

    С публичным полем health разработчик (не обязательно другой), может в другом месте кода напрямую изменять его значение, что приведёт к очевидному багу - какой-то персонаж в каких-то условиях будет просто бессмертным.

    Читаю второе сообщение - делаю вывод, что, чтобы обезопасить себя от бага, нужно сделать публичное поле приватным. Да, именно про безопасность ты не писал. Когда я пишу про "безопасность и защиту", я имею ввиду ту мнимую безопасность которая появляется, когда кто-то просто везде пишет приватные поля и думает, что их никто не будет менять. Будут, как раз таки и потому, что непонятно должно ли это поле быть приватным или нет.

    Предлагаю тебе ещё посмотреть на весь веб

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

    Реальная история?

    Да, это буквально сообщение из чата, сжатое до одного предложения. Можешь зайти в какой-нибудь юнити чат, там подобные истории будут еженедельно присылать.
    Написано
  • Почему рекомендуется использовать private а не просто ставить везде Public?

    K0TlK
    @K0TlK
    Василий Банников,
    К сожалению (или к счастью) у меня на полке таких книг нет. Пример будет?

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

    А зачем эта дополнительная ценность нужна для принятия решения о закрытии полей?
    Сделаем всё приватным.

    Сделал все приватным, а потом тебе нужно в разных местах ui одни и те же данные отобразить по-разному, твои действия? Переделать приватное поле под свойство? Так это же рефакторинг, нельзя так делать, сложно, да и данные наружу выходят, а так нельзя, это же инкапсуляцию нарушает (или нет?).

    Сделать публичное поле приватным - breaking changes.

    Зачем поле, которое изначально было публичным, делать приватным? Просто так захотелось? Инкапсуляции хочешь? Зачем полю в принципе менять модификатор доступа? Если делаешь поле приватным, то оно изначально задумывается как поле, к которому доступа извне не должно быть ни у кого. Не знаю что здесь сложного для понимания, больше я одно и то же повторять не буду.

    Как такое ограничения сделать при помощи публичных полей? Да никак.

    Смотрю в книгу - вижу фигу. Лучше бы со свежей головой прочитал все мои сообщения в этой ветке, потому что я явно дал понять, что я не против использования приватных полей в принципе, а против бездумного втыкания их везде, потому что "так безопасно, ничто не сломается", от кого там что защищать - непонятно, ведь, если мне нужно будет достать данные из приватной переменной, я просто поменяю модификатор доступа этой переменной на публичную или использую рефлексию. И, если публичные поля все ломают и делают плохо, почему же софт, написанный на С кучу лет назад, работает лучше(быстрее, меньше багов), чем тот ужас, что выпускают сейчас (можешь сравнить вижуал студию до того, как она перешла с плюсов на C# и после).

    Как я и писал раньше, вся эта непомерная "защита и безопасность" - бред и может сработать только с новичком, который не понимает что такое программирование и будет просто брать и менять данные, не задумываясь о том, может ли это как-то навредить и нет ли других путей использования данных. Как пример подобного бреда - термин инкапсуляции, который в разных ресурсах описывается по-разному и существует в таком виде только лишь, чтобы продавать разные книжки или курсы человеку, который в этом всем не разбирается.
    Сидеть и ограничивать себя в возможностях использовать данные так как тебе хочется, подбирать паттерны часами, надеясь найти подходящий, пытаться соблюдать "лучшие практики", солид, кисс, драй, ай, вай, а потом плакать в тг чатах, что уже год делаешь клон флеппи берд и не можешь доделать, потому что сложно все очень и запутанно. Типичный современный "программист".
    Написано
  • Почему рекомендуется использовать private а не просто ставить везде Public?

    K0TlK
    @K0TlK
    Василий Банников, Плохо гуглил.
    66d7c39b4f062732558412.png

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

    Если тебе это не очевидно, соболезную.
    В чем заключается ценность приватных полей, если они абсолютно везде? Каким образом понять, что поле следует сделать публичным?
    Предвосхищая зеркальный вопрос на вопрос:
    • Если у тебя в проекте условно 5% приватных полей от всего кол-ва полей, то ВНЕЗАПНО, приватные поля не просто так понапиханы, а они должны тут быть. И говорит о том, что они должны тут быть тот факт, что приватные поля - редкость, исключение из правил.
    • Поле следует сделать приватным, если оно не должно быть доступно никому извне даже для чтения. Как пример - мьютекс должен быть приватным.

    Удивительно сложный рефакторинг - нажать две кнопки в райдере или любом другом иде.

    Зачем тогда приводить этот пример, если он примитивный и несостоятельный? Можешь, вместо того, чтобы отвечать на все остальные вопросы, привести пример того, как реализовать статы персонажа (сила, ловкость и тд) не используя публичные поля и чтобы это все было потом удобно использовать.

    В чем заключается хрупкость? То, что мододел сломал все, не почитав документацию, проблема исключительно мододела.
    Написано
  • Почему рекомендуется использовать private а не просто ставить везде Public?

    K0TlK
    @K0TlK
    Василий Банников, Во-первых, я не про тот индирекшен, чтобы понять про какой я говорю, загугли значение этого слова.

    Во-вторых, каким образом жит компилятор уберет тебе прыжки по указателям в случае с классами?

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

    В-четвертых, этому примеру с хп уже миллион лет. Если разработчику больше 12 лет (от роду), он прекрасно будет понимать, что должна быть какая-то функция/метод для нанесения урона и не будет менять хп напрямую.

    В-пятых, удобная и гибкая система модов может быть реализована только с повсеместным использованием публичных полей, чтобы как можно меньше ограничивать мододелов.
    Написано
  • Почему рекомендуется использовать private а не просто ставить везде Public?

    K0TlK
    @K0TlK
    Если никогда не задумывался, то пора начать задумываться, вместо того, чтобы задавать этот вопрос в интернете. В интернете тебе напишут десятистраничные пасты о "безопасности", невозможности изменить поле извне и о том как хорошо иметь везде приватные поля. В реальном мире бездумное использование приватных полей приводит:
    К нечитабельному коду. Когда вместо публичного поля используется конструкция типа
    [SerializeField] 
    private TypeName _field1;
    [SerializeField] 
    private TypeName2 _field2;
    
    public TypeName Field1 => _field1;
    public TypeName Field2 => _field2;

    или еще хуже:
    [field: SerializeField] public TypeName Property {get; private set;}


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

    К тому, что ты не будешь понимать с первого взгляда на код, действительно ли эта переменная настолько важная, что должна быть приватной или приватной ее сделал бездарь, который насмотрелся видео на ютубе / (начитался статей в интернете / книг) от таких же бездарностей.
    Написано
  • В чем принципиальная разница в unity между private и public?

    K0TlK
    @K0TlK
    leremin, Табличка "не трогать" Васю не остановит, как я и написал выше, если он захочет что-то изменить, он заменит приват на паблик. Если эта табличка висит абсолютно везде, то ее польза начинает превращаться во вред, т.к. становится невозможно сходу определить где приватное поле означает, что все сломается, если его изменить, а где оно просто так впихнуто, потому что так сказали "умные дяди" в книжке.

    Твой пример несостоятельный. Во-первых, зачем кому-то может понадобиться изменять поле версии? Во-вторых, даже если ты изменишь это поле, то запустишь программу, чтобы проверить работает ли то, что ты сделал, программа не будет работать, откатишь изменения назад. И опять же, если бы поле версии было приватным, а всё остальное подавляющее большинство полей - публичными, то сразу было бы понятно, даже тому самому Васе, что это поле трогать не нужно. Но в ситуации, когда у тебя 10 приватных полей и одно публичное свойство, которое возвращает данные из приватного поля, и так по всему проекту, становится невозможным определить действительно ли это поле настолько важное, что оно должно быть приватным.
    Написано
  • В чем принципиальная разница в unity между private и public?

    K0TlK
    @K0TlK
    jaroslav1245, В контексте юнити - паблик поля видны в инспекторе, прайват - нет. Больше различий нет.

    Приватными поля делают потому что в какой-то книжке/статье/видео на ютуб кто-то написал/сказал, что так нужно делать и так правильно. В реальности же, в подавляющем большинстве случаев, приватные поля попросту не нужны и мешаются, вынуждая тебя плодить немыслимое количество методов (отобразить данные в ui, подсчитать что-то, основываясь на части данных этого класса, повзаимодействовать с другим классом). Аргумент с безопасностью абсолютно бредовый. Что мешает Васе изменить приватное поле на публичное или использовать рефлексию и достать данные этим способом? Если Вася захочет, он сделает свое грязное дело и никакие приватные поля его не остановят.

    Ограничение доступа к данным, когда объект находится в каком-то неправильном состоянии, как написал алекс - один из немногих(если не единственный) адекватных юзкейсов приватных полей. Но таких случаев крайне мало, на ум приходит только многопоток и использования мьютекса, чтобы ограничить доступ к данным из разных потоков. Методы, которые кидают исключения, избегай, т.к., потом эти исключения нужно будет обрабатывать, это лишняя сущность, которую нужно будет поддерживать.
    Написано
  • Проблема с кодом в Unity Ecs, как исправить?

    K0TlK
    @K0TlK
    Ты пытаешься использовать метод конвертации, который заменили другим. Гугли документацию к Entities последней версии
    Написано
  • Нашёл скрипт но он инвертированный по горизонтали в юнити?

    K0TlK
    @K0TlK
    Найди другой, который не инвертирован.
    Написано
  • Как бы вы оптимизировали большую сцену в 2D игре?

    K0TlK
    @K0TlK
    mayton2019, мудрый филин, если ты не разработчик игр или не разработчик на юнити и не знаешь работают ли твои идеи, то может не нужно давать советы в той области, в которой ты не разбираешься?

    Весь код

    Движение 10000 юнитов находится в самом низу, занимает 5 строчек кода.

    Скрин из профайлера в эдиторе.
    65cb5bea8e5eb824716010.png

    Как можешь видеть, движение 10000 юнитов занимает 0.05ms
    Рендер занимает 7ms и он занимает так много времени из-за конвертации float3 в vector3, если делать умнее и конвертировать только матрицу, а не отдельно позицию, вращение и скейл, времени оно занимать будет меньше.
    При этом я никак не фильтрую сущности, отрисовываются абсолютно все 10000
    И это метрики из эдитора.

    Вот скрин из билда:
    Ссылка на имгур

    Верхнее число - фреймтайм, нижнее - количество кадров в секунду
    Это на 10000
    А вот на 100000:
    Ссылка на имгур
    Делай выводы
    Написано
  • Как бы вы оптимизировали большую сцену в 2D игре?

    K0TlK
    @K0TlK
    Евгений Иванов, проседает потому что их юнитевский батчинг обрабатывает и отправляет на отрисовку даже ту геометрию, что не попадает в камеру. если нужно отрисовывать и обрабатывать только то, что находится на определенной дистанции от персонажа или попадает в камеру, делай свой батчинг и отрисовывай спрайты сам через rendermesh/rendermeshinstanced/rendermeshindirect
    Написано
  • Как синхронизировать Input с FixedUpdate?

    K0TlK
    @K0TlK
    input ни с чем не синхронизирован. это просто метод, который ты вызываешь там, где тебе нужно. фиксед апдейт вызывается движком не каждый кадр, а раз в определенное время, поэтому и персонаж прыгает через раз. замени фиксед апдейт на обычный апдейт и не делай ту дичь с флагами, что написана в ответе.
    Написано
  • Как лучше сделать проверку для возможности использования предмета?

    K0TlK
    @K0TlK
    yraiv, и снова одна проверка в кадр, не повлияет абсолютно ни на что
    Написано
  • Как лучше сделать проверку для возможности использования предмета?

    K0TlK
    @K0TlK
    нет никакого правильно. твой вариант нормальный, что ты там хочешь оптимизировать? 1 рейкаст в кадр никакой роли не сыграет абсолютно, он по времени даже одной десятой миллисекунды не займет.
    Написано
  • Как считать время у большого количества объектов?

    K0TlK
    @K0TlK
    yraiv, не будет оно лагать. просто не используй юнитевский апдейт в предметах, а обновляй их из одного места. всё. если будет лагать, тогда будешь думать как лучше сделать
    Написано
  • Как считать время у большого количества объектов?

    K0TlK
    @K0TlK
    yraiv, 500 штук и у тебя уже лагает? или ты думаешь, что будет лагать? 500 раз сравнить числа для процессора как капля в море.
    Написано