Здравствуйте, dmitrypr, Вы писали:
D>Записали новое видео об особенностях использования значимых типов в .NET я думаю многим будет интересно http://www.enterra.ru/blog/typesindotnet/
Структуры это ValueType, т.е. значения (сами данные).
Когда мы говорим инкапсуляция, то подразумеваем сокрытие внутреннего представления (данных) и выставления наружу только методов (или свойств).
Сказанное означает, что говорить об инкапсуляции в структурах бессмысленно.
А кроме того, загляните во Framework design guidelines. Когда нужно использовать структуры!?
In general, structs can be very useful but should only be used for small, single, immutable values that will not be boxed frequently.
Свойства и приватные методы в структурах сделаны только для удобства.
Не нужно городить "архитектуру" на структурах.
Всё сказанное выше — личное мнение, если не указано обратное.
Re[2]: Об особенностях использования значимых типов в .NET
Здравствуйте, Философ, Вы писали:
Ф>Когда мы говорим инкапсуляция, то подразумеваем сокрытие внутреннего представления (данных) и выставления наружу только методов (или свойств). Ф>Сказанное означает, что говорить об инкапсуляции в структурах бессмысленно.
Это почему же? Я могу написать структуру, которая будет хранить int, а выставлять наружу исключительно методы возвращающие, например, string.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[3]: Об особенностях использования значимых типов в .NET
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, Философ, Вы писали:
Ф>>Когда мы говорим инкапсуляция, то подразумеваем сокрытие внутреннего представления (данных) и выставления наружу только методов (или свойств). Ф>>Сказанное означает, что говорить об инкапсуляции в структурах бессмысленно.
H>Это почему же? Я могу написать структуру, которая будет хранить int, а выставлять наружу исключительно методы возвращающие, например, string.
Можешь, но зачем так делать?
Приведи хотя-бы один пример из реальной практики, когда это было бы оправдано.
Я на шарпе (и не только) написал множество сотен килобайт кода, но с разбегу не вспомню ни одного случая, когда мне бы пришлось описывать структуру.
PInvoke не в счёт.
Всё сказанное выше — личное мнение, если не указано обратное.
Re[4]: Об особенностях использования значимых типов в .NET
Здравствуйте, Философ, Вы писали:
H>>Это почему же? Я могу написать структуру, которая будет хранить int, а выставлять наружу исключительно методы возвращающие, например, string. Ф>Приведи хотя-бы один пример из реальной практики, когда это было бы оправдано.
Ну, необязательно string. См DateTime, TimeSpan, бинарный размер (в кило-мега-йоттабайтах), стаж сотрудника (лет-месяцев-дней) и т.п.
Можно привести более замороченные примеры: TypeHandle, CancellationToken и т.д. и антипаттерны типа энумератора в List<T>, куда ж без них.
Re[5]: Об особенностях использования значимых типов в .NET
Приведи хотя-бы один пример из реальной практики, когда это было бы оправдано.
Встроенные в .net типы — плохой пример.
S>См DateTime
Этот тип — это вообще какой-то треш.
К нему туча претензий, начиная с того, что нельзя сравнивать два DateTime'а если они для разных временных зон.
Они некоторыми своими решениями тучу палок в колёса разработчикам понаставили, особенно этим.
Почему нельзя было сделать всего два типа, вместо трёх (TimeZone и TimeSpan), а всяческие day/week/.. сделать методами TimeZone, принимающими TimeSpan в качестве параметра?
Зачем нужно было прятать Value, кому от этого лучше стало? Тоже самое TimeSpan касается.
Какую абстракцию выражает свойство Now для DateTime?
Now вообще-то часы должны возвращать. Оно нужно потому, что, например, на сервере и на клиенте может быть разное время.
В связи с вышесказанным пример кода:
if (clientTime.Now != serverTime.Now)
throw new MistimingException();
Я не понимаю, о чём думали люди, которые делали этот тип.
S>... бинарный размер (в кило-мега-йоттабайтах), стаж сотрудника (лет-месяцев-дней) и т.п.
Для этого точно нужны отдельные типы?
Почему стаж сотрудника нельзя выразить с помощью TimeSpan?
S>CancellationToken
Это больше похоже на сущность(с поведением). Думаю, его сделали структурой только из соображений оптимизации.
Про остальное можно сказать примерно также как и про DateTime. Люди в Microsoft далеко не всегда следуют своим же гайдам.
ЗЫ: Когда мы начинаем говорить о ValueType'ах, то приходится несколько отступать от ООП. Вот здесь
Здравствуйте, Философ, Вы писали:
Ф>Приведи хотя-бы один пример из реальной практики, когда это было бы оправдано. Ф>Встроенные в .net типы — плохой пример.
Взаимоисключающие параграфы?
S>>См DateTime Ф>Этот тип — это вообще какой-то треш.
1. Реализация даты-времени в подавляющем большинстве библиотек не имеет принципиальных отличий кроме стартовой точки отсчёта и размерности тика.
2. Ругаться, что тип без поддержки таймзоны не поддерживает таймзоны несколько нелогично, тем более что
* Есть DateTimeOffset
* Поддержка/неподдержка tz не особо влияет на сам факт инкапсуляции.
3. остальные претензии вообще к сабжу не относятся.
Ф>Я не понимаю, о чём думали люди, которые делали этот тип.
Тип делался одним из первых, лет 15 назад. Предугадать действительно важные варианты использования, особенно в начале проектирования — тот ещё гемморой. Посмотрите на конкурентов из тех времён. У кого сделано лучше?
S>>... бинарный размер (в кило-мега-йоттабайтах), стаж сотрудника (лет-месяцев-дней) и т.п. Ф>Для этого точно нужны отдельные типы?
1. Ок, как передавать бинарный размер? Лонгом?
2. Как насчёт перевода в base10, определённый в IEC/ГОСТ (угу, 1 ГБ==10^9 байт)?
Ф>Почему стаж сотрудника нельзя выразить с помощью TimeSpan?
Потому что с точки зрения предметной области стаж измеряется строго в годах-месяцах, и только пояснения к правилам исчисления стажа — превесёлый документ в 50 страниц A4 12-м шрифтом
С точки зрения реализации, напротив, удобней хранить стаж в днях (необязательно соответствующих календарным дням).
S>>CancellationToken Ф>Это больше похоже на сущность(с поведением). Думаю, его сделали структурой только из соображений оптимизации.
По большому счёту в CancellationToken нет поведения, только свойство Отменено (да/нет). То, что внутри прячется CancellationTokenSource — это уже деталь реализации. И то это справедливо не всегда, см CancellationToken.None.
Ф>Про остальное можно сказать примерно также как и про DateTime. Люди в Microsoft далеко не всегда следуют своим же гайдам.
[кэп]
Для начала неплохо бы изучить сами гадлайны. В них предусмотрено несколько уровней требований, по аналогии с RFC 2119.
[/кэп]
Случаи, когда код фреймворка явно нарушает свои же гадлайны можно пересчитать по пальцам. В любом случае, приводить исключения как опровержение правила — не самая логичная штука
Ф>ЗЫ: Когда мы начинаем говорить о ValueType'ах, то приходится несколько отступать от ООП. Вот здесь
хороший пример.
Абстрактное ООП в вакууме вообще малоприменимо на практике. Особенно если учесть что ООП возникло не как согласованная теория, а как обобщение практик, применимых эдак десятилетия три назад. И гораздо чаще применялось для раскрутки и продаж технологий, а не как инструмент для решения проблем.
Если есть значимые типы, то должны быть и не значимые, так типчики без изысков.
