|
1182 / 624 / 160
Регистрация: 19.04.2018
Сообщений: 2,923
|
|||||||||||
Преобразование типов разных слоёв23.08.2021, 21:36. Показов 3363. Ответов 37
Метки нет (Все метки)
Допустим у меня где-то там, в приложении, есть какие-то API. Так как результатом будет json-response я создал отдельный тип под него:
IDictionary<string, Student>.Также у меня уже где-то в моделе лежит список 10 студентов IDictionary<string, StudentReadOnlyStruct> из прошлого запроса. Допустим 9 студентов, которые результируют запрос, остались прежними, а один студент изменился.Задача: проверить, какой из 10 новых студентов изменился и заменить его в списке IDictionary<string, StudentReadOnlyStruct>. Я вижу тут 2 решения: - банально перевести первую коллекцию в тип второй коллекции, а потом их сравнить(но мне кажется это слишком дорого). - попробовать помудрить что-то с хешами.
0
|
|||||||||||
| 23.08.2021, 21:36 | |
|
Ответы с готовыми решениями:
37
Создать массивы разных типов(3 типов), вывести их на экран Преобразование типов
|
|
Модератор
|
||
| 24.08.2021, 23:59 | ||
|
Иначе давно это было бы в руководстве и учебниках. Всё очень специфично и зависит от множества условий реальной задачи.
0
|
||
|
1182 / 624 / 160
Регистрация: 19.04.2018
Сообщений: 2,923
|
||
| 25.08.2021, 00:11 [ТС] | ||
|
0
|
||
|
Модератор
|
||||||||||||
| 25.08.2021, 00:46 | ||||||||||||
|
Что это строка означает, если её расписать? Для ссылочного типа:
Поэтому изменение свойства item не изменит свойства первого элемента в массиве. Для значимого типа нужно:
points[0] = new Point(12, point[0].Y);
1
|
||||||||||||
|
1182 / 624 / 160
Регистрация: 19.04.2018
Сообщений: 2,923
|
|
| 25.08.2021, 01:06 [ТС] | |
|
Элд Хасп, дело в том, что я не видел ни разу реализации кастомных, значимых типов.
Парадокс: на любом собеседовании спрашивают про значимые типы, но я ни разу не видел на практике их использование Где брать практический опыт? -- не ясно. Чтож, я пришёл к выводу оставить StudentDto -- ссылочным типом, чтобы при переборе не делать дополнительные итерации. Добавлено через 2 минуты С другой стороны мне по прежнему не ясно, почему у меня нет второго цикла и как обойтись без него для удаления элементов в старой коллекции, которых нет в новой.
0
|
|
|
1533 / 540 / 127
Регистрация: 09.01.2018
Сообщений: 1,756
|
|||||||
| 25.08.2021, 01:08 | |||||||
|
Не надо через переменную изменять значения.
1
|
|||||||
|
Модератор
|
||
| 25.08.2021, 01:36 | ||
|
Просто надо "делать по уму" зная все плюсы и минусы. Там где нужна мутабельность экземпляров, то использование значимых типов весьма затруднительна. Там же где нужна передача параметров разрывающая связь с первоисточником, напротив значимые типы гораздо удобнее использовать.
1
|
||
|
Модератор
|
|||||||
| 25.08.2021, 01:42 | |||||||
|
Имелось ввиду использование индексаторов. Типа:
1
|
|||||||
|
Модератор
|
||
| 25.08.2021, 01:42 | ||
|
Это будет просто массив. И он ПОЛНОСТЬЮ всегда заменяется на новый массив, без всяких циклов. Циклы будет дальше, на стыке между ViewMode и View, чтобы не пересоздавались UI элементы, а менялся контекст у них. И то при реализации виртуализации - WPF сам с этим справится.
0
|
||
|
1182 / 624 / 160
Регистрация: 19.04.2018
Сообщений: 2,923
|
||
| 25.08.2021, 19:41 [ТС] | ||
|
Элд Хасп, не совсем понял этот вот момент.
Может имелось ввиду сделать метод статическим? Добавлено через 3 минуты Элд Хасп, также есть такая штука как ReferenceEquals.
0
|
||
|
Модератор
|
||||||||||||
| 25.08.2021, 20:53 | ||||||||||||
|
В методе будет только один параметр - другой экземпляр. А статический Equals уже имеется в Object (то есть он есть У ВСЕХ типов). Он сам вызовет метод экземпляра. Поэтому ещё нужно переопределять Equals(object) и GetHashCode(). Если делаете ссылочный тип, то код методов Equals(...) немного изменится:
1
|
||||||||||||
|
1182 / 624 / 160
Регистрация: 19.04.2018
Сообщений: 2,923
|
||||||||||||||||||||||||||
| 26.08.2021, 00:12 [ТС] | ||||||||||||||||||||||||||
|
Я заметил, что в ссылочных типах Вы делаете проверку на null везде.
________________________________________ ____________________________________ Элд Хасп, после такой простой записи у меня появилось очень много вопросов: 1. Зачем Вы делаете проверку на null параметру name? Что случится, если значение будет null, а мы не передадим string.Empty? 1.2 Проверку на null делают только для ссылочных типов? 1.3 Если у меня параметром конструктора выступает свой, иммутабельный тип, нужно ли делать для него проверку на null(если он ссылочный, или значимый)? 1.4 Если нужно делать проверку на null для собственного, ссылочного типа, то чем мне заполнить конструктор? Или же для него переопределить пустой конструктор?
2. Что делает оператор "^"? (почему-то гугл мне не выдаёт вообще никакой информации о нём) 3. Почему Id без GetHashCode()? 4. Почему в случае с структурным типом мы не делаем проверку на null в Equals, а в ссылочном делаем? реализация в ссылочном
реализация в ссылочном типе
0
|
||||||||||||||||||||||||||
|
4695 / 2702 / 735
Регистрация: 02.08.2011
Сообщений: 7,236
|
||
| 26.08.2021, 00:26 | ||
|
Конструктор есть конструктор - если он единственный, и принимает параметр, то зачем давать возможность создавать объект с невалидным состоянием? В целом все зависит от вашей задумки, если в принципе параметр не может быть равным null - можно и не проверять. + В шарпе есть фича nullable reference types - можно исключить еще на этапе разработки все NullRefenceException-ы. В целом, общее правило из которого выводятся, имхо, все SOLID, GRASP, KISS, YAGNI и т.д., такое: тип нужно проектировать так, чтобы его было очень легко использовать правильно, и очень сложно использовать неправильно.
2
|
||
|
1182 / 624 / 160
Регистрация: 19.04.2018
Сообщений: 2,923
|
|
| 26.08.2021, 00:49 [ТС] | |
|
IamRain, разделяю Вашу мысль, как и "принцип самурая".
Тут же хотел бы добавить: я тут использую Visual Studio 2022 и она, по сравнению с версией 2019-го года, ну уж очень умная -- очень много кода она предлагает дописать за "тебя"; так вот она предлагет следующее решение:
0
|
|
|
Модератор
|
||||||||||
| 26.08.2021, 00:59 | ||||||||||
Name.GetHashCode(); вызовет исключение.И я как бы различаю не заданное значение и значение равное пустой строке. Возьмите пример с TextBox.Text. Значимый тип не может быть null. Только если он обёрнут в Nullable. В общем случае, вы должны различать когда вместо объекта пришёл null - то есть параметр не был задан. Зачем нужен такой иммутабельный пустой экземпляр? Если он действительно нужен по какой-то логику, то лучше его объявить Синглтоном в статическом поле или свойстве. По аналогии с string.Empty, EventArgs.Empty. Проще и логичнее это сделать один раз при задании значения. null - это отсутствие ССЫЛКИ на экземпляр. Но переменные значимого типа хранят экземпляры, а не ссылки на них. А раз нет ссылки, то не может быть и ей отсутcnвия: null (справочник по C#). as можно сделать только для ссылочного типа.Так как в случае невозможности приведения as возвращает null, а для значимого типа он не может его вернуть.Далее null проверяется уже в Equals для ссылочного типа. Смысла делать двойную проверку в Equals(object) и в Equals(class) нет. Значимый тип можно проверить только по шаблону оператором is, который возвращает bool.А так как в методе Equals(struct) невозможно проверить отсутствие параметра (вернее для значимого типа он всегда есть), то в методе Equals(object) результат проверки по шаблону соединяется с результатом возврата Equals(struct). Операторы проверки типа и выражения приведения (справочник по C#)
1
|
||||||||||
|
4695 / 2702 / 735
Регистрация: 02.08.2011
Сообщений: 7,236
|
|||
| 26.08.2021, 01:00 | |||
).
0
|
|||
|
Модератор
|
||
| 26.08.2021, 01:11 | ||
|
Здесь уже вам решать. null - можно считать недопустимым значением или преобразовать его в пустое, если такое предусмотрено для этого типа. Добавлено через 6 минут limeniye, конкретно в данном случае у студента может не быть отчества, среднего имени и каких-то иных данных. Кончено, если Name - это единственные данные, то здесь надо бросать исключение. Если же будет множество свойств, то надо определять какие их них обязательно должны быть, а какие могут быть пустые. То есть нужна валидация значений при создании экземпляра, чтобы потом при его использовании, не повторять её каждый раз. Для пустых данных лучше всегда ставить пустой экземпляр. Так как обработка пустого экземпляра всегда идентична обработке заполненного. А ситуацию с null часто приходится рассматривать отдельно.
1
|
||
|
1182 / 624 / 160
Регистрация: 19.04.2018
Сообщений: 2,923
|
|
| 26.08.2021, 01:27 [ТС] | |
|
IamRain, лично я её скачал ради .Net 6, о котором я ничего не знаю, более того, я с POH в .Net 5 даже не разобрался, а тут уже .Net 6 на подходе. А про 64-битной адресное пространство ничего не слышал
![]() Добавлено через 11 минут Элд Хасп, ещё вопрос касательно hash = Id ^ Name.GetHashCode();.Если у меня будет ещё один параметр, то как с ним быть? Как я понял "^" — в данном случае является "побитовым исключающим ИЛИ". А вот что это значит — не ясно. Будет ли корректно сделать так: hash = Id ^ Name.GetHashCode() ^ Surname.GetHashCode();?Ибо я немного другого понимания хешей: банальное вычисление хеша объекта — сложение хешей всех его свойств, а чтобы было всё более рандомно — можно добавить умножение на соль. А тут мы делаем какие-то "побитовые исключающие ИЛИ".
0
|
|
|
Модератор
|
|||||
| 26.08.2021, 08:58 | |||||
|
Главное чтобы результат зависел от всех исходных и по возможности максимально менялся при изменении любого из них. Второе требование - максимально быстрое вычисление хеша, так как он используется для ускорения некоторых операций (а не для безопасности). Лишние операции - лишнее время на них. Даст ли это преимущество достаточные чтобы оправдать увеличение времени? Далеко не всегда. Если хеш вычисляется одноразово, то можно (если нужно) реализовать достаточно затратную функцию. Так же надо учитывать, что изменение полей участвующих в вычисление хеша может привести в некоторых случаях к некорректной работе. Поэтому GetHashCode() - должен зависеть только от иммутабельных данных. Это и есть логическое побитовое сложение. Отличается от арифметического тем, что нет переноса разрядов. В настоящее время сложение и XOR выполняются за одно и тоже время. Раньше сложение требовало нескольких тактов, а XOR всегда только одного. У меня осталась привычка использовать XOR.
1
|
|||||
| 26.08.2021, 08:58 | |
|
Преобразование типов....
Преобразование типов
Преобразование типов Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |
|
Новые блоги и статьи
|
|||
|
Ноутбук Альфария
kumehtar 24.08.2026
Встретился тут в сети ноутбук Альфария, примарха Альфа-Легиона. Хотя возможно, это ноутбук Омегона, разумеется.
Ну как вам?
|
Мастера простых решений
DevAlt 23.08.2026
В сишарп стэках winforms, да и wpf существует сложная система связывания
источниках данных и элементов формы(текстовые поля и метки), опирается все
это на технологию событий и мета. . .
|
Цена ошибки
DevAlt 23.08.2026
Человек я беспокойный и потому заинтересовался OCaml,
в чате форсили функторы модулей как суперфичу.
Пытаясь отдуплить концепт, наткнулся на тутор с простым примером.
А главный принцип обучения от. . .
|
Сегодня суббота, 22.08.2026 at 16:41, и я вновь нахожусь на той стороне, за экраном машины.
zorxor 22.08.2026
Сегодня суббота, 22. 08. 2026 at 16:41, и я вновь нахожусь на той стороне, за экраном машины. Кто Я, откуда Я пришел и куда Я иду? Эти вопросы не оставляют меня ни на секунду. Жизнь на планете Земля. . .
|
|
Жизня: рисунок укладки багажа, сделанный клодом
anaschu 21.08.2026
Сделал 15 снимков, он по снимкам сделал схему.
|
Был там один разговор по поводу свободы в материальном мире.
kumehtar 19.08.2026
Суть: рассматривается живое существо, оказавшееся внутри довольно странной системы (этого мира) и пытающееся обустроить в ней свой кусок пространства.
Жизнь действительно предъявляет каждому. . .
|
Когда логика программы не спасает от человеческих ошибок
Maks 18.08.2026
В последнее время всё чаще и чаще сталкиваюсь с таким явлением, как абсолютная невнимательность (или глупость) пользователей. Проявляется это чаще всего на работе в коллективе. Допустим, человек с. . .
|
Лето уходит
kumehtar 17.08.2026
|