C#, кто он?

В C# все типы неявно наследуются от типа System.Object или просто object. Тип object используется для, так называемой, упаковки объектов. Упаковка в синтаксическом виде — это ни что иное, как приведение объекта к типу object

string str = "Hello";
object obj = (object)str;

Надо отметить, что не смотря на все советы Скотта Мэйерса, приведение типов в C# осталось в стиле языка Си.
Итак, что же особенного в данной ситуации. Упаковка объектов в платформе .NET используется повсеместно, что может привести к путанице. Конечно, при неверном приведении среда исполнения выдаст исключение, но мне представляется, что runtime — это уже поздно. Ловить исключения при каждом присвоении смешно, согласитесь.
В качестве примера использования упаковки можно привести операцию клонирования. В интерфейсе IClonable объявлен метод Clone, который возвращает тип object. Служит этот метод только одной цели — создание копии объекта. Давайте посмотрим, на то, как выглядит определение и использование клонирования.

class Sheep : ICloneable
{
    private string theName;
    private int theAge;

    public Sheep(string aName, int anAge)
    {
        theName = aName;
        theAge = anAge;
    }

    public object Clone()
    {
        return new Sheep(theName, theAge);
    }
}

class Program
{
    static void Main(string[] args)
    {
        Sheep dolly = new Sheep("Dolly", 1);
        Sheep dolly2 = (Sheep)dolly.Clone();
    }
}

Представляется мне это всё, мягко говоря, не удобным и плохо читабельным.

Копирование объектов

Раз уж я заговорил о клонировании, то добью эту тему до конца. В C# все типы данных поделены на два вида: структурные и ссылочные. Структурные — это те типы, которые мы, C++ программисты, привыкли называть POD (Primitive Old Data) типами (int, float, bool, …), перчисления и структуры — которые в C# обрели новую жизнь. Все структурные типы являются наследниками типа System.ValueType и память для их объектов всегда выделяется в стеке. Все остальные типы, то бишь классы и интерфейсы, называются ссылочными и наследуются, как уже было сказано, от System.Object или любого производного, кроме System.ValueType. Память для объектов ссылочных типов выделяется в управляемой куче.
До сих пор всё выглядит сносно, но теперь давайте представим всё на деле. Допустим, у нас есть некая структура, содержащая какие-то данные.

struct Data
{
    public int theData;

    public Data(int aData)
    {
        theData = aData;
    }
}

class Program
{
    static void PrintIncrementedData(Data data)
    {
        Console.Write("Incremental data: {0}n", ++data.theData);
    }

    static void Main(string[] args)
    {
        Data data = new Data(50);
        PrintIncrementedData(data);
        PrintIncrementedData(data);
    }
}

Данная программа не выглядит реально, но тем не менее, ведёт себя так, как мне хочется, а именно, выводит такой результат

Incremental data: 51
Incremental data: 51

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

Incremental data: 51
Incremental data: 52

Одно слово и наша программа перестала работать так, как положено, но продолжила компилироваться без ошибок и предупреждений. Всё это произошло по одной причине: структурные типы при присваивании и передачи в качестве параметров копируются по значению, а ссылочные, как видно из названия, — копируют только ссылку на объект в памяти.
Не знаю, какой тайный смысл разработчики C# вложили в структуры, но трудно обнаруживаемые ошибки, связанные с их использованием представляются более, чем вероятными.

Константность

Здесь я хотел бы поговорить о таких понятиях, которые с C++ называются константными методами и константными возвращаемыми значениями. Если быть точнее, то возвращаемое значение просто имеет константный тип. Но формулировки не столь важны, в C# нет ни того, ни другого. Методы в C# всегда возвращают ссылку на объет ссылочного типа или копию объекта структурного типа. Чем это чревато. Давайте посмотрим на пример из книги «C# и платформа .NET» Эндрю Троелсена, описанный в третьей главе, в разделе, посвящённом инкапсуляции. Так как этот пример там размазан по нескольким параграфам, я соберу его и немного дополню, смысл от этого не изменится.

class FullName
{
    public string firstName;
    public string secondName;

    public FullName(string aFirstName, string aSecondName)
    {
        firstName = aFirstName;
        secondName = aSecondName;
    }
}

class Emploee
{
    private FullName theFullName;

    public Emploee(FullName aFullName)
    {
        theFullName = aFullName;
    }

    public FullName Name
    {
        get { return theFullName; }
    }
}


class Program
{
    static void Main(string[] args)
    {
        Emploee emploee = new Emploee(new FullName("William", "Gates"));
        FullName name = emploee.Name;
        name.firstName = "Linus";
        name.secondName = "Torvalds";
        Console.Write("1: {0} {1}n", emploee.Name.firstName,
            emploee.Name.secondName);
        Console.Write("2: {0} {1}n", name.firstName, name.secondName);
    }
}

Не смотря на то, что автор утверждает, что свойство Name доступно только для чтения, я не применяя никаких усилий изменил значение приватной переменной, в чём легко убедиться, скомпилировав и запустив программу.

1: Linus Torvalds
2: Linus Torvalds

Стоит ли упоминать, что подобное поведение может привести к, довольно плачевным, последствиям. Для того, чтобы избежать такой ситуации не остаётся ничего другого, кроме как скопировать объект FullName перед возвратом из свойства.

public FullName Name
{
    get { return new FullName(theFullName.firstName,
        theFullName.secondName); }
}

Естественно, такой подход гораздо более затратный, нежели возврат константной ссылки в C++.

Делегаты

Увидев в первый раз концепцию делегатов, я пришёл в восторг. Это, действительно, мощная и простая технология позволяет создавать такие конструкции, для которых в C++ применялись колбеки, функторы и обсерверы. Если вкратце, то делегат — это особый вид функции, который объявляется в одном классе, а реализован может быть в другом. Кроме того, один делегат может быть реализован много раз и, при вызове, такого делегата, будут вызваны все его реализации. Давайте посмотрим на примере.

class People
{
    public delegate void SpeakDelegate();
    public SpeakDelegate Speak;
}

class Man
{
    private string theName;

    public Man(string aName)
    {
        theName = aName;
    }

    public void Speak()
    {
        Console.Write("Hello, my name is {0}n", theName);
    }
}

class Program
{
    static void Main(string[] args)
    {
        Man jhon = new Man("Jhon");
        Man alice = new Man("Alice");
        People people = new People();    
        people.Speak +=
            new People.SpeakDelegate(jhon.Speak) +
            new People.SpeakDelegate(alice.Speak);
        people.Speak();
    }
}

При вызове people.Speak будут вызваны методы Speak двух объектов — jhon и alice, а результат будет таким

Hello, my name is Jhon
Hello, my name is Alice

Этот же механизм (с небольшими дополнениями) используется при отправке сообщений. Но об этом я говорить не буду.
В общем-то, всё это выглядит очень красиво, но стоит помнить одну деталь — вызов делегата, у которого нет подписчиков приведёт к генерации исключения и крешу программы, если его не обработать. Следовательно, при вызове делегата мы должны каждый раз проверять, инициализирован ли он, благо не инициализированные делегаты всегда равны null. На первый взгляд, может показаться, что разработчики могли бы гарантировать безопасный вызов делегатов. Но нет, делегаты могут возвращать значение, а какое значение может вернуть то, что не было вызвано? Раз уж я об этом заговорил, то возвращаемым значением делегата — это значение, которое вернёт последняя вызванная делегатом функция.

Оператор foreach

Конечно же, каждый программист на C++ мечтает увидеть в своём любимом языке оператор обхода коллекций foreach. В языке C# он существует. При том синтаксис этого оператора весьма удобен, а работать с ним одно удовольствие.

foreach(ТипЭлементаКоллекции ссылка in коллекция)
{
}

«ссылка» принимает значение каждого из элементов и является именно ссылкой, а не копией. Чтобы Ваш класс мог работать как коллекция в операторе foreach, он должен реализовать интерфейс IEnumerable, в котором всего один метод — GetEnumerator. Вот если Вы используете не встроенные коллекции, то Вам придётся реализовать и интерфейс IEnumerator.

Коллекции

Список всевозможных коллекций в .NET достаточно большой, но что более всего меня вводит в недоумение — это то, что большинство из них не являются обобщёнными. Например, класс ArrayList хранит объекты типа object. Как я уже говорил в разделе об упаковке объектов, это может вызвать путаницу. По какой причине часть контейнеров сделали обобщёнными, а часть — хранящими объекты типа object для меня остаётся загадкой.

Разные мелочи

Из того, что я видел только в C#, стоит отметить статические конструкторы. Это особый вид конструкторов, в котором можно инициализировать статические члены класса. Кроме того, статические члены можно инициализировать прямо при объявлении, даже вызовом какой-либо функции.
Не удалось мне найти достойной замены оператору typedef из C++. Можно использовать ключевое слово using, но распространятся такой «typedef» будет только внутри одного модуля.

Итоги

Подводя итоги, могу сказать следующее: C# — довольно неплохой язык, но в некоторых местах, явно, плохо продуманный. Обойти все изъяны можно, но лучше бы разработчики подумали о них во время проектирования.