Щодо ваших запитів:
Чи є Фасад класом, який містить безліч інших класів?
Так. Це обгортка для багатьох підсистем у застосуванні.
Що це робить модель дизайну? Для мене це як звичайний клас
Усі шаблони дизайну теж є звичайними класами. @ Unmesh Kondolikar правильно відповів на цей запит.
Чи можете ви пояснити мені цей фасад, я новачок у дизайні моделей.
Відповідно до GoF, модель дизайну фасаду визначається як:
Забезпечте уніфікований інтерфейс до набору інтерфейсів у підсистемі. Фасадний малюнок визначає інтерфейс вищого рівня, що полегшує використання підсистеми
Фасад шаблон зазвичай використовується , коли:
- Для доступу до складної системи потрібен простий інтерфейс.
- Абстракції та реалізації підсистеми тісно пов'язані між собою.
- Потрібна точка входу до кожного рівня шаруватого програмного забезпечення.
- Система дуже складна або її важко зрозуміти.
Візьмемо реальний приклад слова веб-сайту cleartrip .
Цей веб-сайт пропонує варіанти бронювання
- Рейси
- Готелі
- Рейси + Готелі
Фрагмент коду:
import java.util.*;
public class TravelFacade{
FlightBooking flightBooking;
TrainBooking trainBooking;
HotelBooking hotelBooking;
enum BookingType {
Flight,Train,Hotel,Flight_And_Hotel,Train_And_Hotel;
};
public TravelFacade(){
flightBooking = new FlightBooking();
trainBooking = new TrainBooking();
hotelBooking = new HotelBooking();
}
public void book(BookingType type, BookingInfo info){
switch(type){
case Flight:
// book flight;
flightBooking.bookFlight(info);
return;
case Hotel:
// book hotel;
hotelBooking.bookHotel(info);
return;
case Train:
// book Train;
trainBooking.bookTrain(info);
return;
case Flight_And_Hotel:
// book Flight and Hotel
flightBooking.bookFlight(info);
hotelBooking.bookHotel(info);
return;
case Train_And_Hotel:
// book Train and Hotel
trainBooking.bookTrain(info);
hotelBooking.bookHotel(info);
return;
}
}
}
class BookingInfo{
String source;
String destination;
Date fromDate;
Date toDate;
List<PersonInfo> list;
}
class PersonInfo{
String name;
int age;
Address address;
}
class Address{
}
class FlightBooking{
public FlightBooking(){
}
public void bookFlight(BookingInfo info){
}
}
class HotelBooking{
public HotelBooking(){
}
public void bookHotel(BookingInfo info){
}
}
class TrainBooking{
public TrainBooking(){
}
public void bookTrain(BookingInfo info){
}
}
Пояснення:
FlightBooking, TrainBooking and HotelBooking це різні підсистеми великої системи: TravelFacade
TravelFacade пропонує простий інтерфейс для замовлення одного з наведених нижче варіантів
Flight Booking
Train Booking
Hotel Booking
Flight + Hotel booking
Train + Hotel booking
API API від TravelFacade внутрішньо дзвонить нижче API підсистем
flightBooking.bookFlight
trainBooking.bookTrain(info);
hotelBooking.bookHotel(info);
Таким чином, TravelFacadeнадається простіший і простіший API без викриття API підсистеми.
Ключові вивезення : (зі статті журналу Pande Kumar )
- Шаблон фасаду більше схожий на помічник для клієнтських додатків
- Шаблон фасаду можна застосувати в будь-якій точці розвитку, як правило, коли кількість інтерфейсів зростає і система отримує завершення x .
- Інтерфейси підсистеми не знають про Фасад, і вони не повинні мати жодної посилання на інтерфейс Фасад
- Фасадну схему слід застосовувати для подібних інтерфейсів , її мета полягає у створенні єдиного інтерфейсу, а не декількох інтерфейсів, що виконує аналогічні завдання
Перегляньте також статтю про створення джерела для кращого розуміння.
