Ссылка на первую часть
Ссылка на вторую часть
Ссылка на третью часть

Ввод данных

Любой инсталлятор должен давать пользователю возможность вводить некоторые стартовый параметры, например, путь к папке, куда будет инсталлирована программа, строка подключения к базе данных, и т.д. Причем, хотелось бы, чтобы это были не просто текстовые поля, а поля, дающие возможность удобного вода данных. Если это путь установки программы, то помимо текстового поля должна быть кнопка «Browse…», если это строка подключения к БД, то пусть рядом будет кнопка для выбора или создания источника данных и т.д.

Ссылка на первую часть
Ссылка на вторую часть

Контентные и контейнерные команды

Некоторые команды подразумевают работу с файлами, изначально хранимыми на компьютере разработчика пакета. Понятно, что эти файлы нужно вместе с пакетом (а желательно, прямо внутри пакета) доставить к потребителю пакета. Попробуем для начала представить себе как это будет работать.
У нас есть экземпляр класса PackageBuilder, которому при конструировании мы указываем аргумент PackageBody, содержащий в себе, помимо всего прочего, команду Command, которая представляет собой корневой узел дерева команд пакета. Метод SaveResult() экземпляра класса PackageBuilder должен рекурсивно обойти все дерево, и для тех команд, которые используют контентные файлы, расположенные на компьютере разработчика, включить в тело пакета содержимое всех этих файлов. В тело пакета он также должен включить xml-файл, в который будет сериализован сам PackageBody с полным описанием пакета и выполняемых им команд.

Ссылка на первую часть

Транзакции.

Напомню, что я собирался реализовать механизм транзакций, позволяющий откатывать блоки операций при возникновении ошибки внутри блока, защищенного транзакцией. Сначала надо решить вопрос с ответственностью за сохранение состояния и за откат операции. Скажу сразу, что архитектура, которую я приведу ниже вырисовалась у меня не сразу, а только после нескольких попыток проектирования и реализации макета, пока у меня не получилось то, что получилось.
Для того, чтобы архитектура транзакций была легко наращиваемой, воспользуемся как и ранее наследованием. При этом возложим ответственность за сохранение состояние и откат к сохраненному состоянию на саму команду. Учтем при этом, что не все команды являются по сути транзакционными. Например, чтение из реестра не может быть частью транзакции, потому что оно ничего не изменяет в системе. А вот запись в реестр – это уже часть транзакции. И создание файла – это часть транзакции.
А поэтому объявим еще один абстрактный класс TransactionalCommand, унаследуем его от класса Command.

Введение

У предлагаемого вашему вниманию цикла статей есть несколько основных целей:

1. Создать полезное программное обеспечение – инсталлятор программ и обновлений.
2. Показать преимущества объектно-ориентированного подхода к разработке ПО и научить создавать легко расширяемые программные архитектуры.

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

1. Реализация механизма транзакций, причем транзакции могут включать в себя не только SQL-транзакции, но и файловые, а также транзакции, связанные с изменением любых других ресурсов ОС, таких как записи в реестре, изменения конфигурационных файлов и т.д.
2. Расширяемость операционной базы инсталлятора, то есть, добавление новых типов команд(операций), как с поддержкой транзакций, так и без нее.

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

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

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

Из последних сил и отбросив такт, ты начинаешь свой рассказ.

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

Предисловие

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

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

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

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

Еще одной метафорой, или скорее принципом разработки, является «принцип самурая», призванный описать «контракт» между функцией и вызывающим ее кодом и заключается в следующем. Любая функция, реализующая некоторую единицу работы должна следовать тому же кодексу чести «бусидо», по которому живет любой самурай. Так, самурай не будет выполнять никаких заданий, противоречащих его «кодексу чести» и если к нему подойти с «непристойным» предложением, то он снесет вам башку раньше, чем вы успеете глазом моргнуть. Но если уж самурай возьмется за дело, то можно быть уверенным в том, что он доведет его до конца (**).