С одноразовостью и многоразовостью аккуратнее. Ибо цель — вывести на заданную орбиту полезный груз заданной массы. На практике оказалось, что многоразовыми кораблями достижение этой цели дороже.
Я эту проблему на Дельфи решил следующим образом: метод подписки возвращает регистрационную метку («гардеробный номерок») — интерфейсную ссылку, очистка которой приведет к отписке. Если ее хранить в поле объекта-подписчика — отписка при его удалении произойдет автоматически. Плюс не нужен специальный метод отписки.
Статический класс — всего лишь контейнер для отдельных подпрограмм, которые для красоты обозваны статическими методами и все тех же глобальных переменных, которые для красоты же обозваны статическими полями. Синглтон — тоже эквивалент глобальной переменной.
На практике имеет смысл использовать статический класс как пространство имен для отдельных подпрограмм, а синглтон лучше вообще не использовать: класс, контролирующий количество своих экземпляров множит на ноль ортогональность, тестируемость и масштабируемость. Для контроля количества экземпляров гораздо лучше использовать фабрики (или другие порождающие паттерны).
Это в хаскеле раздельные пространства имен для функций с параметрами, конструкторов данных, типов данных, переменных типов данных. Ни в дельфи, ни в плюсах, ни в яве, ни в сишарпе такой роскоши нет, приходится использовать те или иные соглашения для улучшения читаемости кода. Плюс в делфи еще нельзя полноценно использовать разный регистр. Отсюда и префиксы — уже по коду видно, где тип, где переменная, где поле, где параметр. С венгерской нотацией (что прикладной, что системной) это не имеет ничего общего.
> А вы пишете на нем тесты или на какой-то другой библиотеки? Думаю эта информация будет полезна для начинающих разработчиков.
Полагаю, что не будет — в команде у молодых выбора инструмента нет. Тем кто работает один — нужны не краткие рекомендации, а толстые книжки и много чужого кода.
> Написание модульных тестов (желательно до кода), которые запускаются постоянно — это способ написание программ, который практически устраняет пункт «9 Отладка»
Модульные тесты являются серебряной пулей только для некоторого класса задач и никоим образом не избавляют от отладки. ЕМНИП по Макконнеллу формальное рецензирование кода ловит больший процент ошибок. Плюс использование способа (TDD) априори важнее выбора инструмента. Но согласен: наличие отдельного пункта про модульные тесты логично и обоснованно.
> Т.е. есть реализация только «пассивного» внесения зависимостей?
Ну изнутри сервиса это наоборот «активное», но увы, в дельфи до 2009 IoC контейнеры слишком сложны в реализации. И у локатора свои плюсы при межязыковом взаимодействии — под Win32 на единую объектную платформу рассчитывать не приходится.
Полагаю экономию одной строчки на описание свойства (и одного хоткея на генерацию простого сеттера) совершенно недостаточной компенсацией за потерю возможности контроля над данными.
> В Delphi есть библиотеки, которые позволяют делать модульное тестирование?
Да. DUnit идет в стандартной поставке.
> Если есть, почему о нем не упомянуто?
Конкретные вспомогательные инструменты не упоминаются специально.
> В разделе «15 Устранение лишних зависимостей» ничего не сказано про IoC-контейнеры. Вместо них много упоминаний про глобальные переменные.
Глобальные переменные и эквивалентные им паттерны (например, синглтон) есть типичная ошибка молодого разработчика.
> Есть ли в Delphi реализация IoC-контейнера?
Для версий от 2009 и выше есть как минимум OpenSource библиотеки. Для младших версий IoC нет ввиду наличия отсутсвия генериков и недостаточных возможностей интроспекции (RTTI есть, но неполная и неудобная для таких целей). Для проектов на Delphi 2007 у нас используется ServiceLocator. Конкретные паттерны и инструменты для устранения зависимостей не упоминаются сознательно — здесь нет однозначно лучшего решения и я не вижу смысла его навязывать.
На практике имеет смысл использовать статический класс как пространство имен для отдельных подпрограмм, а синглтон лучше вообще не использовать: класс, контролирующий количество своих экземпляров множит на ноль ортогональность, тестируемость и масштабируемость. Для контроля количества экземпляров гораздо лучше использовать фабрики (или другие порождающие паттерны).
1. Устранение зависимостей.
2. Рецензирование дизайна.
3. Рецензирование кода.
4. Модульные тесты.
5. Непрерывная сборка.
6. Логирование.
7. Автоматическое функциональное тестирование.
8. Ручное функциональное тестирование.
Попытка сэкономить на чем-то одном уменьшает эффективность всего остального.
Полагаю, что не будет — в команде у молодых выбора инструмента нет. Тем кто работает один — нужны не краткие рекомендации, а толстые книжки и много чужого кода.
> Написание модульных тестов (желательно до кода), которые запускаются постоянно — это способ написание программ, который практически устраняет пункт «9 Отладка»
Модульные тесты являются серебряной пулей только для некоторого класса задач и никоим образом не избавляют от отладки. ЕМНИП по Макконнеллу формальное рецензирование кода ловит больший процент ошибок. Плюс использование способа (TDD) априори важнее выбора инструмента. Но согласен: наличие отдельного пункта про модульные тесты логично и обоснованно.
> Т.е. есть реализация только «пассивного» внесения зависимостей?
Ну изнутри сервиса это наоборот «активное», но увы, в дельфи до 2009 IoC контейнеры слишком сложны в реализации. И у локатора свои плюсы при межязыковом взаимодействии — под Win32 на единую объектную платформу рассчитывать не приходится.
Да. DUnit идет в стандартной поставке.
> Если есть, почему о нем не упомянуто?
Конкретные вспомогательные инструменты не упоминаются специально.
> В разделе «15 Устранение лишних зависимостей» ничего не сказано про IoC-контейнеры. Вместо них много упоминаний про глобальные переменные.
Глобальные переменные и эквивалентные им паттерны (например, синглтон) есть типичная ошибка молодого разработчика.
> Есть ли в Delphi реализация IoC-контейнера?
Для версий от 2009 и выше есть как минимум OpenSource библиотеки. Для младших версий IoC нет ввиду наличия отсутсвия генериков и недостаточных возможностей интроспекции (RTTI есть, но неполная и неудобная для таких целей). Для проектов на Delphi 2007 у нас используется ServiceLocator. Конкретные паттерны и инструменты для устранения зависимостей не упоминаются сознательно — здесь нет однозначно лучшего решения и я не вижу смысла его навязывать.