Кэширование объектов StringBuilder

В текущем проекте народ очень серьезно подходит к вопросам производительности: куча структур, кастомный внешний кэш, и свой собственный object pool для хранения тяжеловесных объектов. Одним из типов объектов, которые хранятся в пуле и используются повторно являются объекты StringBuilder. И я задался вопросом, насколько это полезно.

Начиная с .NET 4.0 реализация StringBuilder-а была существенно переработана. В первых версиях реализация напоминала классический вектор – для хранения создаваемой строки использовалась изменяемый объект System.String (*), размер которой увеличивался вдвое при ее полном заполнении.

(*) Строки являются неизменяемыми лишь с точки зрения внешних кода, но с точки зрения внутреннего (internal) кода pre-.NET4.0 строки были очень даже изменяемыми.

Предусловия в конструкторах наследников

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

abstract class Base
{
    private readonly int _length;
 
    protected Base(int length)
    {
        if (length <= 0) throw new ArgumentOutOfRangeException("length");
 
        _length = length;
    }
}
 
internal class Derived : Base
{
    public Derived(string s)
        : base(s.Length)
    {
        // Проверка бесполезна!
        if (string.IsNullOrEmpty(s)) throw new ArgumentNullException("s");
    }
}

Проблема в том, что конструктор базового класса вызывается до тела метода конструктора Derived (*). В результате, если конструктор наследника принимает составной объект и «выкусывает» часть, которая нужна конструктору базовому классу, то нормально проверить валидность составного объекта не получиться.

Простой Syntax Highlighter на базе Roslyn

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

Вот, например, сколько потребуется усилий, чтобы сделать раскрашиватель синтаксиса, который будет печатать C#-файл в консоль и подсвечивать ключевые слова, строковые литералы и т.п вещи?

Вот как это можно сделать.

О разработке ПО и книге Крега Лармана “Applying UML and Patterns”

DISCLAIMER: это моя типичная рецензия, в ней больше рассуждений на тему книги, чем информации о самой книге! Так что, не проходите мимо!

У стандартного процесса обучения есть интересная особенность. Как только мы решили узнать что-то новое, мы садимся за учебники, идем на курсы и получаем новые знания всеми доступными способами. Через время мы говорим себе «Фффатит!», забиваем на обучение и переходим к практике (на ранних этапах теория переплетается простыми практическими задачами, но они не оказывают существенного значения). После чего, мы начинаем применять наши новые знания на практике, и через время они практически полностью выветриваются из нашей славной головешки и их место занимает опыт.

Итак, что мы имеем? А имеем мы водопадную модель развития, когда на ранних этапах идет обучения, после которого начинается практика. И в чем проблема? А проблема здесь аналогична водопадной модели разработке ПО. Мы просто не в состоянии без должного опыта осознать все прелести сакральных знаний, которые нам пытаются вбить в голову на этапе обучения. У нас еще нет собственных набитых шишек, чтобы оценить эти советы по достоинству.

О роли сборок

В наших с вами интернетах (точнее, у меня в Г+) развернулась небольшая дискуссия на предмет того, когда стоит выделять сборки (.NET Assemblies) в приложении, а когда нет. Там же развернулась и еще одна дискуссия на предмет того, что считать слоем (layer), а что считать слоем (tier). Обсуждение последнего вопроса придется пока отложить, а сегодня я хочу поговорить подумать о том, когда нужно выделять сборки.

ПРИМЕЧАНИЕ
Вот Г+ запись (Лейеры, и Тиры, и Партиции), в которой я цитирую Лармана с объяснением исходной терминологии понятий layer, tier и partition.

Любой букварь про C# и .NET, коих написано over 9000, говорит о том, что сборка (assembly) – это единица развертывания (deployment). Там же обычно говорится о том, что они (сборки) версионны и что CLR обладает мощной системой поиска правильной версии, со всеми GAC-ами, assembly redirect-ами и прочей магией. Что dll hell позади, и теперь мы наконец-то можем заменить одну сборку приложения прямо в продакшне, не сломав все к чертям собачим!

Анализатор исключений на базе Roslyn-а

Уже давно хотел поразбираться с анализаторами на основе Розлина. Тем более, что меня уже был опыт создания плагинов для Resharper-а (R# Contract Editor Extension), поэтому хотелось сравнить разные инфраструктуры и удобство использования. Есть идея переписать этот плагин с помощью анализаторов Roslyn-а, но я решил начать с чего-то попроще.

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

• Повторная генерация исключений с помощью throw ex;
• “Проглатывание” всех исключений с помощью пустых блоков catch {} или catch(Exception) {}.
• “Проглатывание” исключений в определенных ветках блока catch.
• Сохранение в логгах только сообщения ex.Message, теряя при этом потенциально важную информацию о месте возникновения исключения.
• Некорректное пробрасывание новых исключений из блока catch.

Закрытый конструктор базового класса

Вопрос: может ли конструктор абстрактного базового класса Base быть закрытым? Возможно ли в этом случае создать класс-наследник Derived и его экземпляр?

abstract class Base
{
    // WTF! Что с этим делать!
    private Base()
    {
        Console.WriteLine("B.ctor");
    }
}

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