План будущих статей

Знаете...

Ужасно удручён и расстроен я событиями и ситуацией на Украине.

Расстроен и за "наших", и за "не наших".

Посему - депрессия. Что-то плохо всё пишется.

Но планы на самом деле - большие. Если это кому-то нужно в этом УЖАСНОМ мире.

Вот что в планах:

1. Тестируем калькулятор №5. Тесты через "новую архитектуру".
2. Тестируем калькулятор №6. Использование эталонов. Рандомные тесты.
3. Тестируем калькулятор №7. Как правильно сравнивать double. Мак-Конел, и Мак-Кракен и Дорн.
4. Тестируем калькулятор №8. Параметризованные тесты.
5. Почему IStream и IDataObject это ужасно с "архитектурной точки зрения" и как с этим бороться.
6. Автоматические ночные сборки.
7. О практике использования Mutable и Immutable строк. Да и прочих объектов. И почему в Delphi не хватает модификатора const НА МЕТОДАХ объектов.
8. О разнице в интерфейсной и поведенческой эквивалентности в классах, примесях и интерфейсах. И за что я люблю ТИПИЗИРОВАННЫЙ Duck-Typing.
9. Абстрактные классы и как не давать их создавать.
10. Assert'ы и ТЗ.
11. Почему "отдельностоящие методы" ЛУЧШЕ методов КЛАССОВ/интерфейсов и как ЭТО ПОНИЖАЕТ "связность". Повод для данной статьи вот - http://programmingmindstream.blogspot.ru/2014/03/blog-post_12.html
12. Тестируем калькулятор №9. Готовимся к расширению функциональности. Через Dependency Injection. Выделяем класс "TCalculatorOperation".
13. Тестируем калькулятор №10. Расширяем функциональность. От класса TCalculator переходим ко МНОЖЕСТВУ классов TCalculatorOperation.
14. Тестируем калькулятор №11. Размножаем тесты относительно какого-то заданного "итератора". Например по операциям калькулятора.
15. Тестируем калькулятор №12. Тесты и примеси. Скажем так опять.
16. Тестируем калькулятор №13. От класса TCalculatorOperation переходим к "аксиоматике", скриптовой машине и скриптам.
17. Тестируем калькулятор №14. На основе Dependency Injection и "аксиоматике" делаем ДВЕ "морды" калькулятора - на VCL и на FM. Опционально - можно ещё и строковый интерфейс забабахать.
18. Про "инструменты" (тегов) или паттерн Strategy (или Template Method, или Observer). Как они позволяют "внедрять функциональность "сбоку"".
19. По мотивам предыдущей темы - паттерн Context и как не привязываться к  "состояниям" "инструментов". Как делать инструменты объектами БЕЗ СОСТОЯНИЙ (Immutable).
20. По мотивам предыдущей темы - как делать "инструменты" не только объектами и/или интерфейсами, но и class of или Event или даже reference to. И как это позволяет "экономить на спичках", да и не только на них.
21. Ну и ещё по мотивам предыдущих тем привести пример, про TextPara, ParaList, Owner'ов и "декорации" для "баллонов". Почему лучше подавать Owner'а "сверху" (в частности для Painter'ов и HotSpot'ов), а не пытаться получить его "изнутри".