Рефакторинг статических классов

Использование статических классов со статическими методами внутри обладает серией недостатков. Одним из недостатков является появление в коде скрытых зависимостей, так как нельзя понять по интерфейсу либо конструктору некоторого класса зависит ли он от статики или нет. Статические классы нельзя использовать полиморфно. Также подобные классы часто выполняют роль таких себе Helper’ов, Manager’ов, Doer’ов, которым свойственно отвечать за все на свете и разрастаться до немыслимых размеров. Со всеми перечисленными минусами еще можно сосуществовать некоторое время. Однако когда дело доходит до необходимости написания юнит-тестов, от использования статики приходится отказаться в пользу других решений. Рассмотрим их.

Продолжить чтение «Рефакторинг статических классов»

Несколько причин проседания производительности в .NET приложениях

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

Продолжить чтение «Несколько причин проседания производительности в .NET приложениях»

Борьба с побочными эффектами

Простыми словами, побочный эффект или side effect это когда изменение некоторого свойства в одном месте программы непредсказуемо влияет на поведение другой ее части (или многих частей). Побочные эффекты являются ничем иным как багами, исследование которых может потребовать глубокого дебага, продолжительностью от нескольких минут до нескольких часов.
Продолжить чтение «Борьба с побочными эффектами»

Чек-лист для .NET программиста: Уровень доступа к данным

В реляционной модели данные представлены в табличной форме, в то время как в объектно-ориентированных языках данные хранятся в виде графов объектов, что порождает целый ряд трудностей, когда дело доходит до преобразования объектов в табличную форму и наоборот: разные представление связей между зависимыми данными, отсутствие наследования в реляционном мире, несовпадение способов проверки идентичности и тд. (читай The Object-Relational Impedance Mismatch). Даже если программист решит вопрос преобразования, то перед ним возникнет проблема поддержки данных в базе и в оперативной памяти приложения в согласованном состоянии.

Продолжить чтение «Чек-лист для .NET программиста: Уровень доступа к данным»

Шаблоны проектирования: Singleton, Часть 2

Во второй части статей о Синглтоне разберем его плюсы и минусы, поговорим об уходе от классической реализации шаблона используя DI-контейнеры, а также познакомимся с шаблоном Ambient Context.
Продолжить чтение «Шаблоны проектирования: Singleton, Часть 2»

Шаблоны проектирования: Singleton, Часть 1

Синглтон является относительно простым шаблоном проектирования, однако он затрагивает большое количество аспектов разработки программного обеспечения, таких как потокобезопасность, ленивая инициализация, особенности вызовов статических конструкторов, принципы единой ответственности и инверсии зависимостей, юнит-тестирование, утечки памяти и другие.
Продолжить чтение «Шаблоны проектирования: Singleton, Часть 1»

Чек-лист для .NET программиста: Многопоточность и Асинхронность

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

Продолжить чтение «Чек-лист для .NET программиста: Многопоточность и Асинхронность»