Паттерн проектирования «Фасад»

Здравствуйте. Можете по простому объяснить про паттерн проектирования «Фасад», его плюсы, минусы, для чего он...Читая на различных сайтах информацию о нем, все так заумно написано, что трудно понять, хотелось бы узнать о этом шаблоне вашими словами(не заумными). Прошу извинения за такой вопрос.

0

Если очень коротко, то мы прячем вызовы методов некоторых классов за вызовом метода нового класса, который и является фасадом. Это должно повысить читаемость кода

2

Окей. Представьте себе... менеджер памяти того же C#. Ну или даже менеджер памяти Си++. Это вагон с тележкой разнообразных подсистем: поколения, список недавно использованных блоков памяти, список свободных блоков, обходилка всей доступной памяти, какой-то менеджер глобальных параметров, а ещё менеджер собственно виртуальной памяти в системе, а у него свои списки.... А если посмотреть на саму виртуальную память, то там ещё кучи объектов режима ядра, какие-то PTE, кеши MMU и т. п. Всё это дико перевязано между собой, кто-то на кого-то полагается, кто-то кому-то отчитывается, полнейшая санта-барбара.

В общем, весь этот ансамбль работает, чтобы вы могли написать new Something() и получить указатель свой объект, не задумываясь о том, сколько там всего за кулисами происходит. Вот вам и типичный фасад.

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

Естественно, можно делать и фасады внутри фасадов, к которым обращаются фасады. Это просто уровень абстракции. Единственная проблема, которая с ними может возникнуть — это когда их слишком много и все они "текут" (не могут скрыть ту сложность, которую должны скрывать).

2