Уявімо, що ви вирішили провести свої вихідні дуже активно, а тому приїхали на зимовий курорт покататися на лижах. Перед тим як кататися, добре було б пересвідчитися, що ввечері буде де заночувати. Тому ви йдете в місцевий готель і замовляєте собі кімнату, відповідну до ваших вимог. Треба мати на чому кататися, тому ви йдете взяти лижі на прокат. Для того, щоб їх підібрати, у вас запитують вашу вагу, рівень професіоналізму, потім ви підбираєте черевики і палки, для підбору яких у вас ще спитають ваш ріст і розмір взуття.
Із цим усім на хребті ви йдете до каси і купуєте aбонемент на день. Не знаю як вас, але мене таке ходіння дістало б. Я б хотів якийсь термінал, у який вводиш потрібні дані, оплачуєш і тобі зразу персонал видає черевики, лижі, палки, абонемент на день і ключі до номеру в готелі (і дівчину у номер o_O). Якщо ж мені потрібен лише абонемент на день, а лижне спорядження я маю, то абонемент я купую на місці.
Фасад надає єдину «точку доступу» до підсистеми, тим самим спрощуючи її використання та розуміння. В нашому прикладі Фасадом буде термінал-обслуговувальна станція (SkiResortFacade) а підсистемою є ціла купа прокатних будок, кас і готельних комплексів. Звичайно, ви можете прогулятися по курорту, якщо вам це подобається, але якщо дивитися із точки зору розробки програмного забезпечення, то якщо кожен собі буде «гуляти» куди хоче і як хоче, то до добра це не приведе, а лижники-новачки ніколи не будуть знати куди їм йти в першу чергу.