Когда я должен использовать структуру вместо класса?

Question

MSDN говорит, что вы должны использовать структуры, когда вам нужны легкие объекты. Существуют ли другие сценарии, когда структура предпочтительнее, чем класс?

Некоторые люди могли забыть, что:

1. структуры могут иметь методы.
2. структуры не могут быть унаследованы.

Я понимаю технические различия между структурами и классами, я просто не чувствую, что когда использует структуру.

Answer 1

когда вам действительно не нужно поведение, но вам нужно больше структуры, чем простой массив или словарь.

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

Answer 2

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

Answer 3

Хмм ...

Я бы не использовал сборку мусора в качестве аргумента за / против использования структур против классов. Управляемая куча работает во многом как стек - создание объекта просто помещает его на вершину кучи, что почти так же быстро, как и размещение в стеке. Кроме того, если объект недолговечен и не выдерживает цикл GC, освобождение происходит бесплатно, поскольку GC работает только с памятью, которая все еще доступна. (Поищите в MSDN, есть серия статей по управлению памятью .NET, мне просто лень копаться в них).

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

В любом случае, эти четыре пункта в статье MSDN, опубликованной выше, кажутся хорошим ориентиром.

Answer 4

Я думаю, что лучший ответ - это просто использовать struct, когда вам нужен набор свойств, класс, когда это набор свойств и поведений.