Login
Как это работает?
402 просмотров
Перейти к просмотру всей ветки
in Antwort Murr_0005 20.02.10 14:02
// Быстрое создание "контейнеров данных" без логики.
У них и так есть универсальный контейнер данных - DataSet. При том, что даже типизацию можно делать в динамике. И логика, пусть не вся необходимая, присутствует.
---
В моем посте я должен был бы поставить ударение на "без логики". Кстати логику можно всегда будет приписать, но позже
Второй момент - класс, как таковой, можно сгенерировать. Со всеми полями, пропертями и частью логики. Тут проблем совсем нет. Проверено.
---
Не спорю. А может быть автоматические свойства создали для нытиков, которые на отрез отказывались применять Свойства взамен открытым полям
?. Также приятно писать/читать код с минимальным количеством букав
Поясни. Дело в том, что там не стателес по определению. Параметры остаются в полях объекта, но изменение - побочный эффект вызова метода. Сие не есть гут.
---
Согласен, что сие не есть гуд. Я воспринял эту запись как случай отделения логики от данных.
Почему-то всегда стараюсь поддерживать объект в полной готовности. Т.е. пересчитываю сразу как только получил необходимые данные. Есть, конечно, ситуации, в которых на пару тысяч присваиваний и пересчетов приходится один запрос на данные, но это не типично. Но даже если пересчет нужно отложить до обращения к проперти - проблем нет - private Calc() { ... } - доступно объекту, но невидимо пользователю.
---
Здесь вообще очень тяжело выдумывать правила, но когда я работаю с чужим классом, я ожидаю, что get/set проперти не повлечет длительные вычисления. Если это невозможно, то процессом вычисления лучше управлять извне (метод Calc), тогда работу с объектом можно организовать наилучшим оптимальным способом. Также я стараюсь поступать со своими классами.
У них и так есть универсальный контейнер данных - DataSet. При том, что даже типизацию можно делать в динамике. И логика, пусть не вся необходимая, присутствует.
---
В моем посте я должен был бы поставить ударение на "без логики". Кстати логику можно всегда будет приписать, но позже
Второй момент - класс, как таковой, можно сгенерировать. Со всеми полями, пропертями и частью логики. Тут проблем совсем нет. Проверено.
---
Не спорю. А может быть автоматические свойства создали для нытиков, которые на отрез отказывались применять Свойства взамен открытым полям

Поясни. Дело в том, что там не стателес по определению. Параметры остаются в полях объекта, но изменение - побочный эффект вызова метода. Сие не есть гут.
---
Согласен, что сие не есть гуд. Я воспринял эту запись как случай отделения логики от данных.
Почему-то всегда стараюсь поддерживать объект в полной готовности. Т.е. пересчитываю сразу как только получил необходимые данные. Есть, конечно, ситуации, в которых на пару тысяч присваиваний и пересчетов приходится один запрос на данные, но это не типично. Но даже если пересчет нужно отложить до обращения к проперти - проблем нет - private Calc() { ... } - доступно объекту, но невидимо пользователю.
---
Здесь вообще очень тяжело выдумывать правила, но когда я работаю с чужим классом, я ожидаю, что get/set проперти не повлечет длительные вычисления. Если это невозможно, то процессом вычисления лучше управлять извне (метод Calc), тогда работу с объектом можно организовать наилучшим оптимальным способом. Также я стараюсь поступать со своими классами.