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

На данный момент изучаю шаблоны проектирования и пробую применять их на практике
но из-за небольшого опыта работы с ними и отсутствия менторства в этом деле прошу у вас помощи.

Есть, например, задача - сделать стрипт для связи с людьми.

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

$object = Communication::GetDriver('sms');
$object->setMsg($text);
$object->setTelephone($phone);
$object->send();


Но может потребоваться отправить совершенно другим способом, например, в соцсеть.

$object = Communication::GetDriver('socialNetwork');
$object->setMsg($text);
$object->setIdUser($id);
$object->send();


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

А если использовать шаблоны то как объединить классы? Может быть, есть методы, как сделать лучше?
    

Ответы

Ответ 1

Стоит. Только нужно внести ясность.

Обычно полагают, что код пишется "на один раз" или "код слишком простой". На практик
часто оказывается, что "да, оно одноразовое, но надо добавить это...и это". В итог
рождается привычка сразу делать структурно - выделить классы, за которыми спрятать лапшу (точек расширения не надо, просто порядок), а в случае веба взять любой фреймворк, а не тешить себя мыслями "да тут делов то ерунда, роутинг простой, шаблоны не надо"

Практически всегда есть смысл разделить на логгеры, манагеры, ридеры, чтобы оперироват
более высокими уровнями абстракции и спрятать за ними детали, если вы не пишете админские скрипты или не фрилансите (написал, отдал, забыл)

Главное не забывать, что шаблоны призваны решать общие проблемы общими способами. Поэтому не должно быть "ооп ради ооп" и "шаблоны ради шаблонов". 
Тут многие совершают ошибку - начитаются умных книг и пытаются применить шаблон.

Суть в том, что шаблоны - общие решения, которые как то названы. При решении пробле
люди приходят к общим решениям, называют его и пишут в книжку. И шаблоны полезны - знани
шаблонов может подсказать приемлемые варианты и мозг приучается видеть их сразу. Впрочем, даже если не знать ни одного, то на практике все равно сам их изобретаешь. Также помогают в коммуникации (назвать шаблон проще, чем пояснять, что за структура классов и как она связана).
Но решать то нужно задачи, потому на задачах и нужно акцентироваться, а не на шаблонах.

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

Так что разбираться в шаблонах полезно - это как перенимать чужой опыт решения типичны
проблем. И использовать полезно. Но чтобы избежать попадания в ловушку "шаблоны ради шаблонов" следует использовать прием, каким шаблон решает задачу, закодить его и остановиться.


Ответ 2

Вопрос "стоит ли использовать шаблоны" - это всё равно что вопрос "а стоит ли использоват
тапочки" - не имеет однозначного ответа без конкретики. В твоём случае пример есть, и по примеру: стоит, и это шаблон адаптер. НО, хотелось бы ответить не только по поводу этого случая, а более глобально.  

Шаблоны проектирования не обязательно двигают дизайн в хорошую сторону. У всего ест
обратная сторона. Хороший код должен быть максимально читаем любыми прогерами, и долже
быть прост - таковы одни из основных современных тенденций программирования. Шаблон
делают код более гибким - но они его зачастую усложняют. Фабрики - плодят классы, синглтон - рушит инкапсуляцию, деревья - требуют сложную логику для удобной работы с ними, декораторы - сиильно усложняют понимание работы "целого", нарушают SRP, и.т.п.  Есть и фундаментальные паттерны - например стратегия, шаблонный метод, строитель: хочешь не хочешь, а будешь их использовать, если используешь наследование.

Но, это не значит - что паттерны GoF плохи. Они позволяют сделать сложную систем
простой без излишних умозаключений программиста. Ключевое слово тут - сложную. Есл
известно ТЗ на конечную систему/подсистему - можно расчитать, насколько она сложная, и если простая - то паттерны лишний раз не пихать, а если сложная - использовать паттерны по максимуму, внося ясность и гибкость. Рассчитать - это как раз обязанность архитектора, или сотрудника, выполняющего его обязанности(лида).

А если ТЗ нет, или ТЗ лишь итерация проекта, или пишете проект на удачу(совершенн
не зная что впереди): то следует применять к коду эволюционный подход. Это значит, чт
пока всё просто и проект только начинается, можно смело забыть про паттерны. Как тольк
появилось узкое место, которое "течёт", в котором сложный код, или не хватает гибкости: рефакторите код, применяете паттерны для упрощения и повышения гибкости. Это соответствует принципу YAGNI . Конечно этот принцип не противоречит тому, чтобы взять фреймворк за основу проекта, что уже даст годную архитектуру даже без модификаций: ведь ваш код будет вне кода фреймворка, правда это потребует более "прокачанных" программистов. 

У YAGNI также есть одна проблема - зачастую заказчик ставит "срочные задачи", которы
просто не дают времени на встраивание паттернов и рефакторинг тогда, когда в них появилас
необходимость. Или же программист - у которого нет мотивации впахивать, чтобы сделать суперпроект: просто забивает на то, что заказчик не увидит. Это решается путём обозначения YAGNI-способа развития проекта между заказчиком и исполнителем при старте проекта. 

Так что вердикт - паттерны это очень полезно, но очень очень плохо - когда их лепят не к месту. Семь раз отмерь, один раз отрежь. Надеюсь археология вопроса была полезна.

P.S. Этот вопрос ломал мне голову от первых потугов работы программистом: все стать
пестрили слоганами "используй паттерны", "паттерны - добро", "не знаешь паттерны - са
виноват". А всё оказалось не столь однозначно, почему то об обратной стороне медали мало писали в статьях про паттерны, и наивные программисты вроде меня бросались всё делать через них..


Ответ 3

Шаблоны использовать, однозначно, стОит.

Напишу сначала общие мысли, а потом применительно к вашей конкретной задаче.

Общие мысли:
Все шаблоны проектирования - это микс лучших решений, простейших решений, наиболе
понятных решений, наименее трудозатратных решений. Это опыт поколений, который нам оставили предыдущие разработчики. 

Шаблоны проектирования - это автомобиль с бензиновым двигателем вместо осла, эт
телега на колесах вместо мешков на спине, это ракета в космос вместо слонов на черепахе. 

Шаблоны проектирования - это решение тех проблем, которые у вас пока еще не возникли, но обязательно возникнут, если вы не будете им следовать. 

Шаблоны проектирования - это короткие выводы из многотысячестраничной макулатуры
это естественный отбор наиболее приспособленных к жизни решений, это простые истины, которые всем известны, но не все сумели подобрать для них слова. Это хорошо, просто, быстро и эффективно.

Теперь применительно к вашей конкретной задаче:
Вы пишете:


  Стоит ли заморачиваться с шаблонами? Может следует сделать это отдельными классами все? 


Вы противопоставляете шаблоны проектирования отдельным классам для реализации тог
или иного механизма, но это неверно. Ведь у вас в любом случае будет отдельный класс для работы с SMS, отдельный для 
socialNetwork, в идеале, для каждой социальной сети будет отдельный класс. Именн
они, эти классы, должны передаваться в качестве аргумента в ваш метод GetDriver. И они должны реализовывать один и тот же интерфейс. 

Такая схема одновременно будет соответствовать всем шаблонам проектирования и буде
более простой в реализации. Почему более простой? Потому что мозгу всегда просто цепляться за что-то конкретное, стандартное и понятное, чем реализовывать каждый раз одни и те же идеи разными способами.

Вместо выводов:
Если вы вдруг решили просто мне поверить на слово - зря. Сомневайтесь! Шаблоны тож
неидеальны. Вы - новое поколение, которое сделает новые открытия. Попытайтесь сформулировать, что в существующих шаблонах не так. Если вам это удастся - мы прочтем вашу книгу ;)


Ответ 4

Применять шаблоны проектирования определённо стоит.

За время существования ООП был накоплен довольно большой опыт. Позднее этот опы
был структурирован и обобщён для родственных между собой задач. Собственно так и появились шаблоны.

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

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

В противном случае, пытаясь улучшить реализацию с помощью шаблонов вполне вероятно вместо пользы нанести серьёзный вред.

Разбираясь в шаблонах Вы не только перенимаете полезный опыт. Анализ шаблонов способствует более глубокому пониманию ООП и архитектуры ПО.
Только, повторюсь, чтобы достигнуть положительного эффекта нужно использовать шаблон
правильно и там где это действительно нужно, а не реализовывать шаблоны просто ради них самих.


Ответ 5

Касательно примера в оп-посте, возможно вам стоит ознакомиться с более общими принципами ООП, такими, как SOLID. 

В вашем случае, согласно принципе Open-Closed, ваши CommunicationDriver'ы следует отнаследовать от CommunicationDriverAbstract:

abstract class CommunicationDriverAbstract 
{
    public function setMsg($msg) {
        ...
    }

    abstract function setRecipient($recipient);
}


Ответ 6

Шаблоны проектирования - это метод увеличения повторного иcпользования кода.
Сейчас от них никуда ни денешься, они везде.
Время затраченное на их изучение окупается с лихвой, особенно для типовых задач.
Хотя проектирование строго сверху-вниз дает более оптимальные решения, оно значительно дороже.   

Попробуйте придумать новый алгоритм или математическую формулу, и вы поймете.