О вреде изменяемых значимых типов. Часть 2

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

 

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

Disposable структуры

Предположим, у нас есть простенькая структура, реализующая интерфейс IDisposable:

DI Паттерны. Constructor Injection

Когда речь заходит о внедрении зависимостей (Dependency Injection), то у большинства разработчиков в голове возникает образ конструктора, через который эта зависимость передается в виде интерфейса или абстрактного класса. Именно об этом виде управления зависимостей писал Боб Мартин в своей статье Dependency Inversion Principle, поэтому не удивительно, что он является самым известным.

Описание

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

Наследование vs Композиция vs Агрегация

Между двумя классами/объектами существует разные типы отношений. Самым базовым типом отношений является ассоциация (association), это означает, что два класса как-то связаны между собой, и мы пока не знаем точно, в чем эта связь выражена и собираемся уточнить ее в будущем. Обычно это отношение используется на ранних этапах дизайна, чтобы показать, что зависимость между классами существует, и двигаться дальше.

Рисунок 1. Отношение ассоциации

Управление зависимостями

Приложите все усилия для того, чтобы вы управляли зависимостями в приложении, а не зависимости управляли вами.
Мнение автора статьи по поводу зависимостей

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

[ANN]ounce книг 11’2012

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

Это не список рецензий, а всего лишь перечень книг, которые я сам с удовольствием прочитаю в ближайшее время. Так что мое мнение основано скорее на имени автора и какого-то «средневзвешенного» мнения народа в наших с вами интернетах, и оно вполне может измениться после более близкого знакомство с этими творениями. Тем не менее, все они, как минимум, заслуживают нашего с вами внимания и достойны добавиться в бесконечный список книг на полке “to-read”.

Фреймворки, библиотеки и зависимости

В одной из последних статей Ayende привел очень толковое определение разницы между библиотекой и фреймворком:

«Главное отличие библиотек от фреймворков в том, что фреймворк запускает ваш код, и, в общем случае, контролирует свое собственное окружение; в то время, как библиотека – это нечто, что вы используете из своего кода, контролируя свое окружение самостоятельно».

И это очень правильное определение. Фреймворк определяет окружение, используя «push» модель взаимодействия с приложением: в большинстве случаев фреймворк сам вызывает код приложения через механизм виртуальных методов, методы обратного вызова и т.п. Пользователю нужно лишь «вклинить» свой собственный код в «слоты», представленные фреймворком (не зря ведь в русскоязычном сообществе для термина “framework” используется «каркас»).

Немного о сборке мусора и поколениях

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

Итак, большинство современных систем сборки мусора (Garbage Collector, GC) используют поколения для более эффективного освобождения короткоживущих объектов. Существует эвристическое правило, которое говорит о том, что большая часть вновь созданных объектов используются очень короткое время и их спокойно можно будет удалить при первой же возможности.

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