„Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.“
(Gang Of Four)
Идеята на тази design pattern е да служи като „фасада“ между потребителят и някоя друга, доста по-сложна структура, по начин, по който потребителят да няма нужда да знае много за въпросната структура, a да работи с нея през „фасадата“, която фасада вече трябва да знае много за въпросната структура. И по този начин – да опрости интерфейсът за достъп към цялата структура.
Нека си спомним за т.н. Law of Demeter – ако имаме т.н. „влакче“ от класове, които се наследяват например така: „А бива наследен от В, а пък B бива наследен от C…“, ако трябва A да използва методи на C, да не трябва да използва (да „минава през“) B, a да може директно да вика методи на C.
С Facade design pattern можем да спазим това правило.
Примерна ситуация би била, ако пишем или използваме някаква библиотека, която е доста сложна откъм OOP, можем ние сами да напишем една „фасада“, с която да улесним използващите библиотеката и да няма нужда те да познават OOP схемата и.
Какво представлява една „фасада“ от чисто програмна гледна точка?
Може да е например един „wrapper“ клас, чиито методи да викат методи на системата зад фасадата, които методи биха били нужни на потребителя.
И да не забравяме, че във Facade можем да викаме методи на НАПЪЛНО НЕЗАВИСИМИ ЕДИН ОТ ДРУГ КЛАСОВЕ, по този начин „сглобявайки“ си своя логика от различни „парчета“.
От този клас вземи този и този метод, от онзи клас вземи онзи и онзи метод…
Добър въпрос би бил дали Facade допуска добавяне на логика или само използва логиката на подсистемата, пред която стои.
Да, допуска.
„A facade is free to add its own “smarts” in addition to making use of the subsystem.„
Head First Desing Patterns
Use the Facade pattern when:
- you want to provide a simple interface to a complex subsystem. Subsystems
often get more complex as they evolve. Демек, ако мислим в перспектива, че дадена система ще се усложнява… - there are many dependencies between clients and the implementation classes of an abstraction. Introduce a facade to decouple the subsystem from clients and other subsystems, thereby promoting subsystem independence and portability. Демек, още един layer между клиента и системата.
Добра идея би била, Фасадата ни да бъде абстрактен клас и отделните и подкласове да са написани според конкретното използване на системата, „зад фасадата“.
Литература: