Стоит ли заморачиваться с шаблонами проектирования?

На данный момент изучаю шаблоны проектирования и пробую применять их на практике, но из-за небольшого опыта работы с ними и отсутствия менторства в этом деле прошу у вас помощи.
Есть, например, задача - сделать стрипт для связи с людьми.
Подробней: Мы говорим что хотим связаться с пользователем определенным способом, задаем вспомогательную информацию для объекта, далее говорим отправить. В идеале вижу использование скрипта в виде с использованием фабрики и стратегии:
$object = Communication::GetDriver('sms'); $object->setMsg($text); $object->setTelephone($phone); $object->send();
Но может потребоваться отправить совершенно другим способом, например, в соцсеть.
$object = Communication::GetDriver('socialNetwork'); $object->setMsg($text); $object->setIdUser($id); $object->send();
Вот и вопрос, как лучше поступить? Стоит ли заморачиваться с шаблонами? Может быть, следует сделать все это отдельными классами? Это будет оправдано? При этом желательно ловить ошибки и вести лог происходящего.
А если использовать шаблоны то как объединить классы? Может быть, есть методы, как сделать лучше?

Ответ

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