changelog:
30.04.2008 после более детального рассмотрения проблемы оказалось что asp ошибочно генерирует классы для тех типов данных где должны быть структуры. однако мои предыдущие выводы остаются в силе.
Сегодня наткнулся на еще одну особенность языка, которая показалось мне не логичной: C# не дает копировать объект. Само по себе это не удивительно и проживает в стандарте достаточно давно. Однако при использовании языка понимаешь, что это ограничение, которое мешает нормальному ходу разработки. Постараюсь в двух словах описать как я рассуждал.
Имя объект на руках необходимо работать с ним в двумя способами - передавать его по ссылке и по значению. От такой схемы мы конечно же выигрываем в большинстве случаев: мы экономим память и делаем передачу любого объекта на вызове функции мгновенной и эффективной. Но с этим приобритается один не достаток: мы теряем надежную защиту данных от изменений и отсутствие простого способа создания немного измененного объекта. C# не имеет функции по умолчанию для передачи объектов по значению и разработчики предлагают нам три варианта: использование искусственных конструкторов копирования, копирования объектов вручную по параметрам или сериализация. В первых двух случаях мы получаем нагрузку на код, который начинает расти в тех местах, где этого можно было бы избежать. Наш второй вариант, вообще губителен для проекта так, как нам требуется дублировать код во всех местах где нам необходимо получить простую копию объекта. Третий вариант - не эффективен по скорости и памяти и так же требует дополнительного кода. Теперь при разработки библиотеки мы должны учитывать один из этих вариантов копирования объекта для удобного использования наших функций пользователем. Конечно же, когда вы разрабатываете проект, как любой хороший разработчик, вы стараетесь следовать данным правилам и везде предусмотреть возможность копирования объекта где это необходимо. В итоге, думаю почти весь ваш код обрастет ненужными вам, но возможно полезными, функциями копирования для потенциальных пользователей вашей библиотеки. Это создаст вам дополнительные хлопоты.
Теперь, учитывая выше сказанное мы само собой предполагаем, что так же рассуждали и разработчики C# и всей .Net платформы. Продумав до мелочей все возможные нюансы и создав для нас такие конструкторы копирования. Однако это не так, первые же попытки работы с ASPX показали, что об создании копий объектов должен думать сам разработчик. Оказывается, что используя Web ссылки на компоненты, в которых используются простые структуры с простыми типами (int), при импорте они генерируются без конструкторов копирования и вы как порядочный разработчик должны создавать специальный код для копирования вручную. А так как код импортируемой компоненты гненрируется каждый раз, вы должны создавать такие функции в отдельном модуле, или использовать один из способов приведенных выше. Думаю это не единственное место где это проявится...
Вот мы рассмотрели еще один минус технологии .Net, которому я бы присвоил метку "дублирование кода". Первый такой случай был мной замечен при работе с конструкцией using, которая не полностью заменяет собой простой проверенный временем деструктор и привязанный к времени жизни переменной.
Ссылки по теме:
Подписаться на:
Комментарии к сообщению (Atom)
0 коммент.:
Отправить комментарий