Совсем недавно один из читателей моего блога спросил моего мнения о применении приемов функционального программирования в таких изначально объектно-ориентированных языках как C#, а также попросил прокомментировать два варианта дизайна кода: одного – чисто объектно-ориентированного, а второго – по его мнению, с уклоном в функциональное программирование. Но поскольку один лишь анализ дизайна потянул на небольшую статейку, то обсуждение интереснейшей темы мультипарадигменного программирования в языке C# мы отложим на следующий раз, а сейчас сосредоточимся исключительно на дизайне.
Постановка задачи
Итак, можно представить, что мы с вами проводим что-то вроде дизайн ревью, входными данными которого является не подробная спецификация с кучей диаграмм, а всего лишь несколько фрагментов кода, по которому нам с вами нужно принять решение, каким путем идти. Основная суть задачи, о которой идет здесь речь, заключается в проектировании иерархии команд (паттерн «Команда»), при этом каждое действие команды состоит из двух составляющей: непосредственной бизнес-логики команды и некоторого завершающего действия. При этом известно, что для одного конкретного вида бизнес-логики может существовать несколько разных завершающих действий.
Команда разработчиков представила два варианта дизайна: первое решение сводится к тому, что завершающее действие в виде делегата передается классу конкретной команды через конструктор, а во втором решении для этого создается соответствующий подкласс. При этом сторонники второго подхода придерживаются мнения, что использование делегатов не является чистым подходом с точки зрения ООП, сторонники же первого подхода считают такое поведение нормальным. Теперь давайте посмотрим на предоставленные нам фрагменты кода.
