Comments 12
А живой рабочий пример есть, когда это бывает полезно?
btw для вопросов есть спец. ресурс Toster.ru.
А так тут есть уже сравниватель, habrahabr.ru/post/269699, а клонировать объект как эталон можно через MemberwiseClose
А так тут есть уже сравниватель, habrahabr.ru/post/269699, а клонировать объект как эталон можно через MemberwiseClose
Пока вообще непонятно, зачем это все нужно.
Вы бы более развернуто что ли написали, где это надо и в чем необходимость именно стандартного решения, а не библиотеки из nuget. Да и если это и нужно(в чем я пока сильно сомневаюсь), то скорее стандартной библиотеке, а никак не языку.
Столкнулся с тем, что в C# как таковом нет понятия «состояния»
Есть. Набор значений внутри определенного объекта и есть его состояние.
нет встроенной удобной возможности запомнить состояние сложного объекта в определенный момент,
А зачем?
Все, что вы описываете, прекрасно реализуется с помощью паттерна (внезапно) State, превращения этого внутреннего состояния в неизменное (т.е., смена состояние — полная замена объекта, описывающего состояние), и сравнения этих состояний. Ну да, можно нафигачить nuget-пакетик, если где-то реально часто встречается.
Вам нужен getHashCode или как он там в шарпе называется.
Есть вариант складывать всё «состояние» в struct, а его в тело класса, а потом сравнивать эти struct'ы. Копирование и сравнение идёт в комплекте.
pls see below
На сколько я понял, метод «IsInSameState» — это что-то вроде расширенного Equals.
Объект может иметь различный смысл в разных ситуациях. На пальцах, скажем, есть объект
Старушка = new Человек {Паспорт = «4606 456356645» Возраст = 88, Пол = Женский, ОтношениеККурению = СмолитКакПаровоз}
Есть сервисы IПенсионныйФонд и IОбществоПоБорьбеСРаком
Для сервиса IПенсионныйФонд не так уж важно, сколько лет стукнуло бабуле. Паспорт совпадает — значит, она и есть.
Для IОбществоПоБорьбеСРаком паспорт вообще не важен, зато Возраст — критерий для сравнения.
В общем, что я хотел сказать: нельзя State задавать атрибутами. Для разных ситуаций состояние можно интерпретировать по-разному. Я не знаю, с какого языка Вы почерпнули сей паттерн, но мне кажется, данный подход (с атрибутами, как Вы предложили), там долго не продержится.
А вообще, наверняка кто-то сталкивался с подобным, надо только поискать.
Объект может иметь различный смысл в разных ситуациях. На пальцах, скажем, есть объект
Старушка = new Человек {Паспорт = «4606 456356645» Возраст = 88, Пол = Женский, ОтношениеККурению = СмолитКакПаровоз}
Есть сервисы IПенсионныйФонд и IОбществоПоБорьбеСРаком
Для сервиса IПенсионныйФонд не так уж важно, сколько лет стукнуло бабуле. Паспорт совпадает — значит, она и есть.
Для IОбществоПоБорьбеСРаком паспорт вообще не важен, зато Возраст — критерий для сравнения.
В общем, что я хотел сказать: нельзя State задавать атрибутами. Для разных ситуаций состояние можно интерпретировать по-разному. Я не знаю, с какого языка Вы почерпнули сей паттерн, но мне кажется, данный подход (с атрибутами, как Вы предложили), там долго не продержится.
А вообще, наверняка кто-то сталкивался с подобным, надо только поискать.
И как архитектурный дизайн, я бы предложил что-нибудь типа stateless-класса StateChecker, который должен единожды инициализироваться правилами проверки состояния. Его можно было бы инстанциировать в нужных местах кода или по аналогии с IEqualityComparer<T> иметь статические синглтоны вроде EqualityComparer.Default для стандартных ситуаций. Но тогда вопрос — чем это отличается, собственно, от IEqualityComparer<T>? Если в нужных местах можно игнорировать какое-то свойство объекта, пожалуйста — напиши свой компаратор, сравнивающий всё, кроме этого свойства.
Sign up to leave a comment.
Нужен ли C#-у «state»?