2009-03-08 2 views
1

У меня есть класс изображения продукта. Это объект с возможностью повторного использования для общей работы с изображениями (например, для продукта, для CMS при работе с изображениями и т. Д.). Это позволит мне установить заголовок файла и отредактировать изображение простыми способами с использованием стандартных классов .NET.Struct vs static class для общего ресурса?

Я могу использовать структуру, что означает, что если я использую структуру в 5 разных местах, это 5 разных мест памяти, но все они незащищены друг от друга. Изменение состояния одного из этих мест памяти не влияет на другие (что является желательным поведением). При запросе объекта он будет помещен в коробку.

Объект основан на экземпляре. Поэтому каждый продукт будет использовать объект продукта и работать с изображением (например, редактировать его название и т. Д.).

Если я создаю статический класс, то есть пять разных мест, относящихся к одному объекту. Поэтому мне нужно будет позаботиться о синхронизации потоков. Я не могу просто написать переменную, поскольку другой доступ может перезаписать переменную, независимо от того, насколько хорошо я синхронизирую доступ к этому общему ресурсу. Поэтому мне всегда нужно возвращать новые переменные. Кроме того, если я использую статический класс, который используется многими различными вызовами, это приведет к тому, что очередь получит доступ к общему ресурсу. Поскольку классы утилит являются статическими, и они просто такие - утилиты - они будут использоваться многими классами в моей кодовой базе. Возможно, не разумно использовать статические классы в этой ситуации?

Как объясняется в документации MSDN, я буду использовать только статический класс для глобального объекта. Таким образом, класс, который инкапсулирует данные о моей кодовой базе - есть только одна база кода, и этот класс будет содержать данные о подсчете строк и т. Д. Это не основано на экземпляре, как класс заказа (1 заказ-1 заказ-1 или более заказов).

В таком виде сценария, это хорошее дизайнерское решение, возможно, вместо использования структуры?

ответ

2

Мне не совсем ясно, что вы хотите использовать этот тип как, но похоже, что лучше всего создать неизменный ссылочный тип. Очень редко нужно создавать свои собственные структуры в .NET (и, в частности, структура «продукта», как будто это почти наверняка неправильный выбор), и статический класс обычно не должен иметь какое-либо изменчивое состояние, кроме потенциально для таких вещей, как счетчики.

Есть ли какая-либо причина, по которой вы не пошли для нормального класса? Сделайте его неизменным, если вы хотите иметь возможность разделить один экземпляр между несколькими «родителями», не беспокоясь о том, чтобы какой-либо родитель менял содержимое - добавьте дополнительные методы, которые возвращают новый экземпляр на основе старого, но каким-то образом изменились, как и String.Replace делает.

+0

Hi. Я намерен создать стандартный класс изображений. Требование относится к движку электронной торговли, но я вижу непосредственный потенциал для повторного использования. Единственная причина, по которой я не обращался за ссылочным типом, заключался в том, что я бы изменил все ссылки, когда 1 ref изменяется. Я предполагаю, что это должно быть неизменным и ref type. – dotnetdev

+0

Yup, звучит как отличный пример того, где подходит неизменяемый ссылочный тип. –

+0

Yup. Объект будет использоваться различными подсистемами системы, поэтому непреложный путь. Похоже, что причина использования структуры основана на невыполнении сценария. Поправьте меня, если я ошибаюсь. Чтобы предотвратить бокс, я мог бы использовать структуру и создать метод, запрашивающий параметр типа значения. – dotnetdev

7

На мой взгляд, настало время беспокоиться о проблемах с производительностью после того, как у вас возникла проблема с производительностью. До тех пор беспокоиться о том, чтобы код работал и поддерживался. В противном случае вы окажетесь в погоне за незначительными выигрышами в производительности или, возможно, при решении неправильной проблемы с производительностью.