Сегодня мы познакомились с понятием Делегирование в ООП. В двух словах: делегирование — это передача ответственности разным объектам. Ниже приведен пример реального мира, который мы использовали для изучения идеи компании, состоящей из разных сотрудников, над задачей сделать компанию более эффективной.

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

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

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

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

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

Визуализация этих взаимодействий была действительно полезной практикой. Я хотел бы узнать больше о делегировании и о том, как более эффективно планировать и реализовывать эту концепцию в будущем. Ждите еще постов на эту тему!