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

Я удивлен, что не считал ни в одном предыдущем ответе это, которое я рассматриваю самым решающим аспектом:

я использую структуры, когда я хочу тип без идентификационных данных. Например, 3D точка:

public struct ThreeDimensionalPoint
{
    public readonly int X, Y, Z;
    public ThreeDimensionalPoint(int x, int y, int z)
    {
        this.X = x;
        this.Y = y;
        this.Z = z;
    }

    public override string ToString()
    {
        return "(X=" + this.X + ", Y=" + this.Y + ", Z=" + this.Z + ")";
    }

    public override int GetHashCode()
    {
        return (this.X + 2) ^ (this.Y + 2) ^ (this.Z + 2);
    }

    public override bool Equals(object obj)
    {
        if (!(obj is ThreeDimensionalPoint))
            return false;
        ThreeDimensionalPoint other = (ThreeDimensionalPoint)obj;
        return this == other;
    }

    public static bool operator ==(ThreeDimensionalPoint p1, ThreeDimensionalPoint p2)
    {
        return p1.X == p2.X && p1.Y == p2.Y && p1.Z == p2.Z;
    }

    public static bool operator !=(ThreeDimensionalPoint p1, ThreeDimensionalPoint p2)
    {
        return !(p1 == p2);
    }
}

, Если у Вас есть два экземпляра этой структуры, Вы не заботитесь, являются ли они единственной частью данных в памяти или два. Вы просто заботитесь о значении (значениях), которое они содержат.

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

Также посмотрите предыдущие вопросы, например,

What' s различие между структурой и классом в.NET?

Я использовал бы структуры когда:

1. объект, как предполагается, только для чтения (каждый раз, когда Вы передаете/присваиваете структуру, он копируется). Объекты только для чтения являются большими когда дело доходит до многопоточной обработки, поскольку они не вознаграждают блокировку в большинстве случаев.

2. объект является маленьким и коротко живет. В таком случае существует хороший шанс, что объект будет выделен на стеке, который намного более эффективен, чем помещение его на управляемой "куче". То, что является больше памятью, выделенной объектом, будет освобождено, как только это выходит за пределы своего объема. Другими словами, это - меньше работы для Сборщика "мусора", и память используется более эффективная.

Я всегда использовал структуру, когда я хотел группироваться несколько значений для того, чтобы пасовать назад вещи от вызова метода, но я не должен буду использовать его ни для чего после того, как я считал те значения. Так же, как способ содержать вещи в чистоте. Я склонен просматривать вещи в структуре, столь же "холостой" и вещи в классе как более полезный и "функциональный"

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

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

Как @Simon сказал, структуры обеспечивают семантику "типа значения" поэтому при необходимости в подобном поведении к встроенному типу данных используйте структуру. Так как структуры передаются копией, Вы хотите удостовериться, что они являются маленькими в размере, приблизительно 16 байтов.

Хм...

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

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

Так или иначе, те четыре точки в статье MSDN, отправленной выше, кажутся хорошей инструкцией.