Pull to refresh

Comments 21

вот теперь то я понял, что именно я реализовывал… делал, а названия не знал.

спасибо за статьи. Просто, кратко, понятно.
Как раз начал изучение паттернов =). Если я верно понял, то Фасад-это просто класс, объединяющий результаты работы некоторых объектов других классов? (наверно глупо поставленный вопрос, просто мне так проще=> лучше запомнится… И вообще кажется понимание паттернов-совсем не сложно, а я сейчас читаю «Банду 4-ех», так там все описано ОТЛИЧНО, но сложно =( Хотя и это, возможно, только для меня так и я не нашел верного подхода к изучению паттернов по ней… Читаю, разбираю, а они забываются в нужных ситуациях примениться). Спасибо за статьи.
Это нормально. Паттерны — это не только готовые рецепты для написания нового кода, но и средство для описания и наведения порядка в имеющемся.
Я так понимаю, любой «продвинутый» контроллер может являться фасадом. Например, как раз он и может осуществлять авторизацию, помимо выполнения своих основных функций.

Здесь, кстати, полезно провести параллели с шаблоном Builder — этот шаблон может не только «создавать», но и «настраивать» произвольное количество объектов, скрывая всю сложность от клиента.
>Я так понимаю, любой «продвинутый» контроллер может являться фасадом.

Может но это не очень хороший вариант, т.к. как он применим только когда есть один вариант использования (web). А что, если вам еще веб-сервис нужно будет слепить? Как правило фассад это почти то же самое что и сервисный слой, по крайней мере я это так понимаю. А дальше этот фассад уже и дергается в контроллерах, веб-сервисах.
На самом деле, многие из нас неявно используют те или иные паттерны. Но четкое понимание их устройства и применимости к ситуациям приносит больше пользы, чем их неявное использование. Плюс знание имен паттернов очень помогает при общении, когда тебя с полуслова понимают: «берем синглтон», «вот тут используй визитора», «а вот здесь нужен адаптер». Еще один момент — при намеренном использовании паттернов часто используются соответствующие имена или префиксы для классов, их реализующих, например, ConnectionFactory, XMLNodeVisitor — это позволяет легко распознавать паттерны при чтении кода.
Синглтон — это уже антипаттерн. Просто к слову :)
Да вот как-то так неожиданно случилось. Основной недостаток — сложность тестирования. Отличная замена синглтонам — тулкит. Тулкит, правда, сам является синглтоном, но единственным в проекте, а при правильной реализации (не монолитный класс, а набор тулзов) лишен всех недостатков обычного синглтона.
Сложность тестирования можно победить, добавив метод setInstance. Главная его проблема — статическая зависимость
Кстати, тулкит пару лет назад как раз в лимбе подсмотрел :) В документации к лимбу хорошее описание было и еще, вроде бы, в статье об инверсии зависимостей.
какая есть литература и источники конкретно по паттернам проектирования?
замечательная. только в русском варианте трудночитаемая.
не воспринимаются все-таки названия паттернов переведенные на русский
Спасибо, почитал, понравилось, теперь намного лучше понимаю как дальше работать над своим проектом.
По паттернам для веб-разработчиков есть отличная книга Фаулера «Архитектура корпоративных приложений». Еще здесь очень неплохо изложено.
Фасад, на мой взгляд, один из наиболее простых для понимания паттернов, и его действительно часто многие используют, даже не зная о нем.
То есть фасадом является, например, любой унифицированный интерфейс для плагинов навроде того же CallService миранды?
Можно ли поправить текст статьи? Текст программы отображается в виде HTML кода: https://habrastorage.org/files/c64/f30/61c/c64f3061ce2a4c59afaab14477fd9bc9.png
Sign up to leave a comment.

Articles