Uzaqdan Fasad. PHP-də fasad dizayn nümunəsi Fasad dizayn nümunələri
Uzaqdan Fasadın təsviri
Şəbəkə səmərəliliyini artırmaq üçün bir sıra obyekt metodları üçün ümumi birləşdirici interfeys təqdim edir.
Obyekt yönümlü modeldə Uzaqdan Fasad nümunəsi kiçik metodları olan kiçik obyektlərlə işi yaxşılaşdırır. Kiçik texnikalar davranışa nəzarət etmək və dəyişdirmək və müştərinin tətbiqi başa düşməsini yaxşılaşdırmaq üçün böyük imkanlar təklif edir. Bu incə dənəli davranışın bir nəticəsidir ki, adətən çoxlu metod çağırışları ilə obyektlər arasında çoxlu qarşılıqlı əlaqə mövcuddur.
Bir ünvan məkanında "incə dənəli" qarşılıqlı əlaqələr yaxşı işləyir, lakin proseslər arasında qarşılıqlı əlaqə yarandıqda hər şey dəyişir. Uzaqdan zənglər daha baha başa gəlir, çünki çox şey etmək lazımdır: bəzən məlumatların təşkili, təhlükəsizliyin yoxlanılması, paketlərin açarlarda yönləndirilməsi lazımdır. Əgər dünyanın müxtəlif uclarında iki proses işləyirsə, hətta işıq sürəti belə rol oynaya bilər. Çətin həqiqət ondan ibarətdir ki, hər hansı bir proseslərarası rabitə prosesdaxili çağırışlardan daha çox israfçıdır. Hər iki proses eyni maşında işləsə belə. Bu performans təsirini hətta tənbəl optimallaşdırma həvəskarları da nəzərdən qaçıra bilməz.
Nəticə olaraq, uzaqdan idarəetmə ilə məşğul olan hər hansı obyekt nəyisə etmək üçün tələb olunan sorğuların sayını minimuma endirən daha ümumi interfeysə ehtiyac duyur. Bu, təkcə metodlara deyil, həm də obyektlərə təsir göstərir. Faktura və onun bütün elementlərini ayrıca tələb etmək əvəzinə, bir sorğuda bütün faktura elementlərini oxuyub yeniləməlisiniz. Bu, obyektin bütün strukturuna təsir göstərir. Kiçik obyektlərin və kiçik metodların yaxşı məqsədi haqqında unutmaq lazımdır. Proqramlaşdırma getdikcə çətinləşir, məhsuldarlıq düşür və düşür.
Uzaqdan Fasad nümunəsi daha çox “incə dənəli” obyektlərin strukturunun üstündə ümumi “Fasad”ı (GOF-a görə) təmsil edir. Bu obyektlərin heç birinin uzaq interfeysi yoxdur və Uzaqdan Fasad heç bir iş məntiqini ehtiva etmir. Bütün Uzaqdan Fasad ümumi sorğuları tabe olan obyektlərə kiçik sorğular toplusuna çevirməkdir.
Fasad naxışının məqsədi
- Fasad nümunəsi bir sıra alt sistem interfeysləri əvəzinə vahid interfeys təmin edir. Fasad alt sistemin istifadəsini asanlaşdıran daha yüksək səviyyəli interfeys müəyyən edir.
- Fasad nümunəsi daha sadə interfeysə malik mürəkkəb alt sistemi əhatə edir.
Həll edilməli problem
Müştərilər mürəkkəb alt sistemin ümumi funksionallığı üçün sadələşdirilmiş interfeys istəyirlər.
Fasad nümunəsinin müzakirəsi
Fasad nümunəsi mürəkkəb alt sistemi vahid interfeys obyektinə daxil edir. Bu, alt sistemi öyrənmək üçün lazım olan vaxtı azaldır və həmçinin alt sistem ilə potensial olaraq çoxlu sayda müştərilər arasında əlaqə dərəcəsini azaltmağa kömək edir. Digər tərəfdən, fasad alt sistemə yeganə giriş nöqtəsidirsə, o zaman qabaqcıl istifadəçilərin ehtiyac duyduğu imkanları məhdudlaşdıracaq.
Vasitəçilik funksiyalarını həyata keçirən Fasad obyekti kifayət qədər sadə qalmalı və hər şeyi bilən “oracle” olmamalıdır.
Fasad Naxış Strukturu
Müştərilər Fasad vasitəsilə alt sistemlə əlaqə saxlayırlar. Müştəridən sorğu qəbul edildikdə, Fasad obyekti onu istədiyiniz alt sistem komponentinə yönləndirir. Müştərilər üçün alt sistemin komponentləri “qaranlığa bürünmüş bir sirr” olaraq qalır.
SubsystemOne və SubsystemThree altsistemləri SubsystemTwo altsisteminin daxili komponentləri ilə birbaşa qarşılıqlı əlaqədə deyil. Onlar SubsystemTwoWrapper "fasadından" istifadə edirlər (yəni daha yüksək səviyyəli abstraksiya).
Fasad nümunəsi istifadəni asanlaşdıraraq alt sistem üçün vahid yüksək səviyyəli interfeysi müəyyən edir. Alıcılar telefonla kataloq məhsulları sifariş edərkən fasadla üzləşirlər. Alıcı müştəri xidmətinə zəng edir və almaq istədiyi əşyaları sadalayır. Xidmət nümayəndəsi yerinə yetirmə şöbəsi, satış şöbəsi və çatdırılma xidmətinə interfeys təmin edən "cəbhə" rolunu oynayır.
- Alt sistem üçün sadə, vahid interfeys təyin edin.
- Alt sistemi əhatə edən "sarğı" sinfini tərtib edin.
- Alt sistemin bütün mürəkkəbliyi və onun komponentlərinin qarşılıqlı əlaqəsi müştərilərdən gizlidir. "Fasad"/"sarğı" istifadəçi sorğularını müvafiq altsistem metodlarına yönləndirir.
- Müştəri yalnız "fasad"dan istifadə edir.
- Əlavə "fasadlar" yaratmağın məqsədəuyğunluğunu nəzərdən keçirin.
Fasad naxışının xüsusiyyətləri
- Fasad yeni interfeysi müəyyən edir, Adapter isə mövcud interfeysdən istifadə edir. Unutmayın, Adapter iki mövcud interfeysi yeniləri yaratmadan birlikdə işləməyə məcbur edir.
- Flyweight çoxlu kiçik obyektlərin necə hazırlanacağını göstərsə də, Fasad bütün alt sistemi təmsil edən tək bir obyektin necə hazırlanacağını göstərir.
- Mediator Fasad-a bənzəyir ki, o, mövcud siniflərin funksionallığını mücərrədləşdirir. Bununla belə, Mediator onların heç birinə xas olmayan həmyaşıd obyektlər arasında funksionallığı mərkəzləşdirir. Həmkarlar Mediator vasitəsilə bir-biri ilə məlumat mübadiləsi aparırlar. Digər tərəfdən, Fasad altsistem üçün sadə interfeys müəyyən edir, yeni funksionallıq əlavə etmir və altsistem siniflərinə məlum deyil.
- Abstract Factory platforma xüsusi sinifləri gizlətmək üçün Fasad-a alternativ olaraq istifadə edilə bilər.
- "Fasad" obyektləri çox vaxt Singleton olur, çünki yalnız bir Fasad obyekti tələb olunur.
- Adapter və Fasad hər iki sarğıdır, lakin onlar müxtəlif növ sarğılardır. Fasadın məqsədi daha sadə interfeys yaratmaq, Adapterin məqsədi isə mövcud interfeysi uyğunlaşdırmaqdır. Fasad adətən birdən çox obyekti sarar, Adapter bir obyekti sarar.
Fasad nümunəsinin həyata keçirilməsi
Sistemin komponentlərə bölünməsi onun mürəkkəbliyini azaldır. Siz Fasad nümunəsindən istifadə edərək sistem komponentləri arasındakı əlaqələri gevşete bilərsiniz. Fasad obyekti sistem komponentləri üçün vahid, sadələşdirilmiş interfeys təmin edir.
Aşağıdakı nümunə şəbəkə xidməti sistemini modelləşdirir. FacilitiesFacade sistemin daxili strukturunu gizlədir. İstifadəçi bir dəfə xidmət üçün müraciət edərək, daha sonra 5 ay ərzində həftədə 1-2 dəfə sorğusuna tam şəkildə xidmət olunana qədər işin gedişi ilə maraqlanır.
#daxildir
Proqram çıxışı:
Obyektlərə təqdim edildi - İndiyə qədər 1 telefon zəngi Elektrikçiyə təqdim edildi - İndiyə qədər 12 telefon zəngi MIS-ə təqdim edildi - İndiyə qədər 25 telefon zəngi yalnız 35 telefon zəngindən sonra tamamlandı
11 mart 2010-cu il, saat 10:30Dizayn nümunəsi "Fasad" / "Fasad"
- Mükəmməl kod
Digər nümunələrin təsviri.
Problem
Bəzi mürəkkəb sistemin alt sistemlərinin asılılığını və onlar arasında məlumat mübadiləsini minimuma endirmək.Təsvir
Mürəkkəb sistemləri layihələndirərkən, sözdə mürəkkəb sistemin daha kiçik və daha sadə alt sistemlərə bölündüyü parçalanma prinsipi. Üstəlik, parçalanma səviyyəsi (dərinliyi) yalnız dizayner tərəfindən müəyyən edilir. Bu yanaşma sayəsində ayrı-ayrı sistem komponentləri ayrı-ayrılıqda inkişaf etdirilə və sonra birlikdə birləşdirilə bilər. Bununla belə, ilk baxışdan aydın olan bir problem yaranır - sistem modullarının yüksək əlaqəsi. Bu, ilk növbədə modulların bir-biri ilə mübadilə etdiyi böyük həcmdə informasiyada özünü göstərir. Bundan əlavə, belə ünsiyyət üçün bəzi modullar digər modulların təbiəti haqqında kifayət qədər məlumata malik olmalıdır.Beləliklə, alt sistemlərin asılılığının minimuma endirilməsi, eləcə də onlar arasında ötürülən informasiyanın həcminin azaldılması əsas layihələndirmə işlərindən biridir.
Bu problemi həll etməyin bir yolu "Fasad" naxışından istifadə etməkdir.
Fasad nümunəsi bir sıra alt sistem interfeysləri əvəzinə vahid interfeys təmin edir. Fasad daha yüksək səviyyəli interfeysi müəyyən edir
Bu, alt sistemin istifadəsini asanlaşdırır.
Sadəcə olaraq, “Fasad” hansısa mürəkkəb alt sistemlə işləmək üçün yüksək səviyyəli əməliyyatlar toplusunu özündə cəmləşdirən obyektdən başqa bir şey deyil. Fasad bu alt sistemin funksionallığını həyata keçirən sinifləri birləşdirir, lakin onları gizlətmir. Müştərinin, əlbəttə ki, ehtiyacı varsa, alt sistem siniflərinə aşağı səviyyəli girişdən məhrum olmadığını başa düşmək vacibdir. Fasad alt sistemlə müəyyən əməliyyatları asanlaşdırır, lakin onun istifadəsini müştəriyə həvalə etmir.
Praktik problem
"Fasad" nümunəsindən istifadə edərək, biz bəzi istifadəçi avtorizasiya alt sistemi üçün vahid interfeys tətbiq edəcəyik. Avtorizasiya alt sisteminin özü (bu nümunədə) şübhəsiz ki, "mürəkkəb sistem" kimi görünmür, lakin nümunənin əsas üstünlüklərini açıq şəkildə əks etdirir.Sinif diaqramı
Diaqrama baxaq. Aydınlıq üçün icazə alt sisteminin çərçivəsi düzbucaqlı şəklində vurğulanır. Authorizator fasadı müştəriyə altsistemlə işləmək üçün vahid interfeys təqdim edir. Bu halda, yalnız bir üsul var - avtorizasiya () lakin daha çox ola bilər. Bu halda, müştəri alt sistemlə işləmək üçün fasaddan istifadə edə bilər və ya onu təşkil edən siniflərdən birbaşa istifadə edə bilər. Avtorizasiya prosesinin özü olduqca sadədir. İstifadəçi adına əsasən verilənlər bazasında müvafiq giriş DB interfeysi vasitəsilə axtarılır. Daha sonra tapılan girişin parolu istifadəçinin göstərdiyi parolla müqayisə edilir.C#-da tətbiq
İcra kodunda Yox sinif PgSQLDB.Sistemdən istifadə;
System.Collections.Generic istifadə edərək;
System.Linq istifadə edərək;
System.Text istifadə edərək;
System.Security istifadə edərək;ad sahəsi Fasad
{
//Mücərrəd istifadəçi sinfi
mücərrəd sinif İstifadəçi
{
qorunan sətir istifadəçi adı;
qorunan sətir passwd;ictimai abstrakt sətir getUserRole();
ictimai sətir getPasswdHash()
{
// Bu sətir heç bir semantik məna daşımır.
// Təbii ki, bu bizə etibarsız parol hash verir
passwd.GetHashCode().ToString();
}
}// İstifadəçini standart istifadəçi kimi təyin edin
sinif DefaultUser: İstifadəçi
{
ictimai DefaultUser(sətir istifadəçi adı, sətir passwd)
{
bu .username = username;
bu .passwd = passwd;
}
{
"DEFAULT_USER" qaytarın;
}
}// İstifadəçini administrator kimi göstərin
sinif Administratoru: İstifadəçi
{
ictimai Administrator (sətir istifadəçi adı, string passwd)
{
bu .username = username;
bu .passwd = passwd;
}getUserRole() ictimai sətrini ləğv edir
{
"ADMINISTRATOR" qaytarın;
}// Verilənlər bazasına giriş interfeysi
DB interfeysi
{
İstifadəçi axtarışı (simli istifadəçi adı);
}// SQLite üçün verilənlər bazası interfeysinin həyata keçirilməsi
sinif SQLiteDB:DB
{
ictimai SQLiteDB (sətir fayl adı)
{
// Verilənlər bazası sürücüsünü işə salın
}ictimai İstifadəçi axtarışı (simli istifadəçi adı)
{
// Stub
yeni NotImplementedException();
}
}// İstifadəçi icazəsi
ictimai etibarsızlıq icazəsi (sətir istifadəçi adı, string passwd)
{
DB db = yeni SQLiteDB("db.sqlite" );
İstifadəçi istifadəçisi = db.search(istifadəçi adı);
əgər (user.getPasswdHash() == passwd)
{
// hər şey qaydasındadır, istifadəçi tanınır
}
başqa
{
// Nəsə xəta baş verdi
yeni SecurityException ("Yanlış parol və ya istifadəçi adı!");
}
}
}sinif proqramı
{
statik boşluq Əsas (sətir args)
{
// Uydurma istifadəçi
string username = "Vasya" ;
string passwd = "qwerty" .GetHashCode().ToString();Authorizer authorizer = new Authorizer();
cəhd edin
{
auth.authorizate(istifadəçi adı, passwd);
}
tutmaq (SecurityException istisna olmaqla)
{
// İstifadəçinin autentifikasiyası yoxdur
}
}
}
}
* Bu mənbə kodu Mənbə Kodu Vurğulayıcı ilə vurğulanıb.
PS: Habraeditor işləməyən tək mənəm?
Oxumadan əvvəl, lütfən, aşağıdakı konvensiyaları və anlayışları nəzərdən keçirin. Bu məqalə müəyyən bir tezliklə yenilənir, buna görə də əvvəllər oxumusunuzsa, məlumatların dəyişmədiyi fakt deyil.
Fasad sinfinə aiddir struktur naxışlar. Müəyyən bir alt sistemin interfeysləri dəsti əvəzinə vahid interfeysi təmsil edir. Fasad nümunəsi alt sistemlərdən istifadəni asanlaşdıran daha yüksək səviyyəli interfeys müəyyən edir.
Mürəkkəb sistemin alt sistemlərə bölünməsi dizayn prosesini sadələşdirməyə imkan verir, həmçinin bir alt sistemin digərindən asılılığını minimuma endirməyə kömək edir. Bununla belə, bu, belə alt sistemlərdən birlikdə istifadənin olduqca çətin olmasına gətirib çıxarır. Bu problemi həll etməyin bir yolu fasad nümunəsini təqdim etməkdir.
Bu, konkret sistemdən asılı olduğu üçün dəqiq icrası olmayan nümunələrdən biridir. Ümumiyyətlə, aşağıdakı transformasiyanı həyata keçirməliyik:
Boz düzbucaqlıda öz aralarında bəzi asılılıqlar olan alt sistemlərimiz var (olmaya bilər). İlk üç blok müştəri kodunun bu altsistemlə qarşılıqlı əlaqədə olduğu üç bölməsini göstərir. Bizim vəzifəmiz sadə, vahid interfeys yaratmaqdır ki, onun vasitəsilə alt sistemlərlə qarşılıqlı əlaqədə olmaq kifayətdir tapşırıq çərçivəsində, olanlar. biz bütün hallar üçün universal interfeys yaratmağa ehtiyac duymuruq, çünki əksər hallarda bu lazımsızdır və daha mürəkkəb qarşılıqlı əlaqələrə və inkişaf vaxtının artmasına səbəb olur.
Aşağıda bir tətbiqin eskizi verilmişdir:
/** * SystemA */ sinif Bank ( ictimai funksiya OpenTransaction() () ictimai funksiya CloseTransaction() () ictimai funksiya transferMoney($miqdar) () ) /** * SystemB */ sinif Müştəri ( ictimai funksiya OpenTransaction() ( ) ictimai funksiya CloseTransaction() () ictimai funksiya transferMoney($miqdar) () ) /** * SystemC */ class Log ( ictimai funksiya logTransaction() () ) sinif Fasad ( ictimai funksiya transferi($miqdar) ( $Bank = yeni Bank(); $Müştəri = yeni Müştəri(); $Log = yeni Log(); $Bank->OpenTransaction(); $Client->OpenTransaction(); $Log->logTransaction("Transaction açıq"); $ Bank->transferMoney(-$miqdar); $Log->logTransaction("Bankdan pul köçürmək"); $Client->transferMoney($miqdar); $Log->logTransaction("Müştəriyə pul köçürmək"); $Bank ->CloseTransaction(); $Client->CloseTransaction(); $Log->logTransaction("Transaction close"); ) ) // Müştəri kodu $Transfer = yeni Fasad(); $Transfer->transfer(1000);
Fasad.
Növ
Struktur dizayn nümunəsi.
Təsvir
Fasad nümunəsi bir qrup obyekti bir xüsusi interfeys altında birləşdirir və öz metodlarına çağırışları həmin obyektlərə yönləndirir.
Lazım gələrsə, şablon istifadə olunur:
- mürəkkəb sistemə girişi asanlaşdırmaq;
- (və ya) sistemə müxtəlif giriş səviyyələri yaratmaq;
- (və ya) sistem və müştəri arasında asılılıqların sayını azaltmaq.
Aydınlaşdırmaq üçün ilk şey odur ki, şablonun təqdim etdiyi interfeys sistemə daxil olan obyektlərin bütün üsullarının cəmi deyil. Belə ümumiləşdirilmiş versiyanın yaradılması “ilahi interfeys”in yaranmasına gətirib çıxaracaq. Bunlar. çox sayda metodu olan, dəqiq müəyyən edilmiş məqsədi olmayan və çox sayda asılılıq yaradan interfeys. Nəticə nümunənin tam əksidir.
Fasadın məqsədi müəyyən bir problemin həlli üçün üsulları ehtiva edən və ya mənbə sisteminin xüsusi abstraksiyasını təmin edən bir interfeys yaratmaqdır. Aşağıdakılar mümkündür:
- şablon interfeysi çağırışlarının sistem obyektlərinə yönləndirilməsi;
- əvvəlcədən müəyyən edilmiş dəyərləri əvəz etməklə metod parametrlərinin sayının azaldılması;
- sistem obyektlərinə zəngləri birləşdirən və/və ya öz məntiqini əlavə edən yeni metodların yaradılması;
- Bəzi orijinal üsullar və xüsusiyyətlər Fasad vasitəsilə əlçatmaz olacaq, çünki problemin həllində rol oynamasın.
Bu yanaşma mürəkkəb sistemin istifadəsini asanlaşdırır. Eyni zamanda, bu, çağırılan metodların sayını və onların çağırışlarının ümumi sayını azaldır. Nəticə tətbiqdəki asılılıqların sayının azalmasıdır.
Qeyd etmək lazımdır ki, Fasad sistem tərəfindən istifadə edilən gizlədilmiş obyektləri tələb etmir. Ancaq bir vacib şərt var: Fasad interfeysinin yaradıldığı müştəri hissəsi yalnız ondan istifadə etməlidir və birbaşa sistem obyektlərinə daxil olmamalıdır. Bu, müştərinin tapşırığını interfeysdə daha dəqiq əks etdirməyə kömək edir.
Bundan əlavə, sistem müxtəlif növ problemləri həll etmək üçün bir neçə Fasad təmin edə bilər. Bu, bir-birinin üstündə və ya eyni müstəvidə yerləşə bilən bir neçə abstraksiya səviyyəsi yaratmağa imkan verir. Müştərilər ya öz işləri üçün xüsusi Fasaddan istifadə edə, ya da birbaşa xüsusi obyektlərlə işləyə bilərlər.
Maraqlı variant Fasad və Abstract Factory şablonlarını birlikdə istifadə etməkdir. Bu halda, Fasad interfeysi obyektlərin özləri ilə deyil, onların interfeysləri ilə əlaqələndirilir. Bu, tətbiqi gizlədir və Abstrakt Fabrikaya onu dəyişdirmək imkanı verir. Bu yanaşma, məsələn, sistem platformadan və ya aparatdan asılı siniflərdən istifadə etdikdə tapıla bilər.
Oxşar nümunələr və onların fərqləri
| Fasad | Bir xüsusi interfeys altında bir qrup obyekti birləşdirir. | O, bir qrup obyektlə işi asanlaşdırır və yeni abstraksiya səviyyəsini təqdim edir. | Xüsusi interfeysi həyata keçirmək üçün lazım olan obyektləri ehtiva edir və ya istinad edir. |
|---|---|---|---|
| Adapter | Obyektin funksionallığını dəyişmədən interfeysini dəyişir. Birdən çox obyekti bir interfeysə uyğunlaşdıra bilər. | Mövcud kodu təkrar istifadə etməyə imkan verir. | Uyğunlaşa bilən obyekti ehtiva edir və ya miras alır. |
| Körpü | Obyekti abstraksiya və həyata keçirməyə ayırır. Obyekt iyerarxiyası üçün istifadə olunur. | Sistemin çevikliyini artıraraq, abstraksiya və icranı ayrıca dəyişdirməyə (miras almağa) imkan verir. | Verilmiş abstraksiya və onun təkmilləşdirmələri (varisləri) üçün metodları təmin edən obyekti (həyata keçirmə) ehtiva edir. |
| Dekorator | Obyektin imkanlarını genişləndirir və davranışını dəyişir. Dekorativ obyekt interfeysini dəstəkləyir, lakin yeni metodlar və xüsusiyyətlər əlavə edə bilər. | Obyektin funksionallığını dinamik şəkildə dəyişməyə imkan verir. Bu miraslığa alternativdir (çoxlu daxil olmaqla). | Tərkibində bəzədiləcək obyekt var. Ardıcıl olaraq adlandırılan obyektlər zənciri mümkündür. |
| Proksi | Obyekti şəffaf şəkildə əvəz edir və ona girişi idarə edir. İnterfeys və ya davranışı dəyişmir. | Obyektlə işi sadələşdirin və optimallaşdırın. Müştəridən gizlədərək öz funksionallığını əlavə edə bilər. | Obyekt və ya ona istinad ehtiva edir və əvəz edilmiş obyektin mövcudluğuna nəzarət edə bilər. |
| Bağlayıcı | Kompozit obyektlər və onların hissələri ilə qarşılıqlı əlaqə üçün vahid interfeys təmin edir. | Bu, müştərinin işini asanlaşdırır və kompozit obyektlərin və onların hissələrinin yeni variantlarını əlavə etməyi asanlaşdırır. | Kompozit obyektlərə və onların hissələrinə interfeys kimi daxil edilir. |
| Fürsətçi | O, obyektin interfeysini dəyişdirmək məqsədi daşımır. Lakin bu, dövlətin çıxarılan hissəsindən məlumatları geri almaq üçün tələb oluna bilər. | Tətbiqdəki obyekt nümunələrinin sayını azaltmağa və bununla da onun resurslarına qənaət etməyə imkan verir. | Obyektin vəziyyətinin kontekstə həssas hissəsini xaric edir, onun çoxsaylı nümunələrini biri ilə əvəz edir. |
İki çox oxşar nümunəyə ayrıca diqqət yetirək - Fasad və Adapter, bir neçə uyğunlaşdırıla bilən obyektlərdən istifadə edir. Sual yarana bilər: fərq nədir? Onların məqsədlərinə diqqət yetirin. Əgər obyektlərin birliyi mövcud interfeysi həyata keçirmək və kodu təkrar istifadə etmək üçün istifadə olunursa, o, Adapterdir. Tapşırığın mahiyyətinin vurğulanması, əməliyyatın sadələşdirilməsi və yeni interfeysin görünüşü Fasadın əlamətləridir.
Yeri gəlmişkən, real vəziyyətlərdə şablonlar “oxşarlığa” deyil, məqsədə əsaslanaraq tətbiq edilməlidir. Buna görə də belə bir sual yalnız təhsil zamanı yarana bilər.
Şablonun ümumi formada həyata keçirilməsi
Şablonu həyata keçirmək üçün aşağıdakı yanaşmalar mümkündür:
- Sistemin nümunəsinə istinad edən ayrı bir sinif yaratmaq. Bu klassik bir seçimdir və həyata keçirilməsi aydın şəkildə vurğulanır, çünki ayrıca obyektdir. ictimai sinif FacadeImpl: IFacade ( özəl AppSubSystem _system; ictimai FacadeImpl(AppSubSubSystem s) ( this._system = s; ) /* Atlandı */ ) Bundan əlavə, sistem nümunəsi Fasad daxilində yaradıla bilər: ictimai sinif FacadeImpl: IFacade ( özəl yalnız oxumaq üçün AppSubSystem _system = new AppSubSystem(); /* Atlandı */ )
- Sistemə Fasad interfeysinin əlavə edilməsi. Fasadın çoxlu müştərisi varsa və onların hər birinin öz şablon tətbiq nümunəsini yaratmağın mənası yoxdursa faydalı ola bilər. ictimai sinif AppSubSystem ( ictimai IFacade FacadeInterface ( almaq; şəxsi dəst; ) ictimai AppSubSystem () ( this.FacadeInterface = new FacadeImpl(bu); ) /* Atlandı */ )
- Varislikdən istifadə edərək sistem sinfinin özündə Fasad interfeysinə dəstək. Tətbiq bütün sistemdə "bulanıq" olur. Bununla belə, indi onun nümunəsi Fasad interfeysinin tələb olunduğu yerlərdə istifadə edilə bilər. Bundan əlavə, sistemin özəl sahələrinə və metodlarına daxil olmaq mümkün olur və zəngləri eyni üsullara yönləndirməyə ehtiyac yoxdur. ictimai sinif AppSubSystem: IFacade ( /* Atlandı */ )
Bütün bu yanaşmalar aşağıdakı kimi yazıla bilər:
- seçilmiş tapşırığın və ya yeni abstraksiyanın funksiyalarını müəyyən edirik;
- biz onları sistemdəki mövcud obyektlərlə əlaqələndiririk;
- şablon interfeysinin inkişafı ;
- həyata keçirəcəyik variantlardan birində:
- zəngləri sistem obyektlərinə yönləndirən ayrıca sinif;
- sistemin özünün sinfində;
- müştəri bir neçə siniflə qarşılıqlı əlaqədə olmaq əvəzinə bir yeni interfeyslə işləyir.
İcra nümunəsi
Məzmun idarəetmə sistemi daxilində sadə bloq yazısı redaktorunun yaradılması nümunəsinə baxaq. Hansı obyektlərin bu alt sistemin bir hissəsi olacağını sadalayaq. Qısalıq üçün nümunə üçün vacib olmayan icazə və digər üsulları siləcəyik.
Əsaslardan başlayaq - sinif tərəfindən təqdim olunan blog yazısı BlogPost. Bu sinif bir qeydin xüsusiyyətlərini və məzmununu saxlayır.
İctimai sinif BlogPost ( ///
Növbəti sinif BlogPostStorage– serverdə blog yazıları üçün saxlama. O, avtorizasiya məlumatlarını təyin etməyə, qeydləri endirməyə və dərc etməyə imkan verir.
İctimai sinif BlogPostStorage ( ///
Orfoqrafiyanı yoxlamaq üçün sadə bir sinif var SimpleSpellChecker.
İctimai sinif SimplepellChecker ( ///
Və sonuncu komponent mətn redaktorudur. Qısalıq üçün onun demək olar ki, bütün üsullarını çıxaraq.
İctimai sinif PostRedaktoru ( ///
Bloq yazısı redaktoruna keçək. Onun alt sistemi belə görünəcək:
İctimai sinif BlogRedaktoru (yalnız oxumaq üçün özəl BlogPostStorage _storage = yeni BlogPostStorage(); ictimai BlogPostStorage Storage ( əldə edin ( bunu qaytarın._storage; ) ) xüsusi yalnız oxunan PostEditor _editor = yeni PostRedaktoru(); ictimai Post Redaktoru Redaktoru ( əldə edin (bunu qaytarın)._editor;) )
Müştəri bu obyektlərdən birbaşa istifadə edə bilər. Amma ona ehtiyac varmı? Diqqətlə baxsanız, aşağıdakı funksiyaların lazım olduğunu görəcəksiniz:
- serverə daxil olmaq üçün təfərrüatları göstərin: Server, Daxil ol, parol;
- girişlərin siyahısını yükləyin: GetPostList();
- redaktə üçün girişi yükləyin: LoadPost();
- yazı xüsusiyyətlərini və mətnini əldə edin: PostProperties, Post Məzmun;
- Girişin orfoqrafiyasının yoxlanıldığından əmin olun: IsSpellCheckComplete;
- yazı göndərin: Nəşr et();
- girişi silin: DeletePost().
Bütün bunlar Fasad üçün interfeys kimi yazıla bilər:
İctimai interfeys IBlogEditorFacade ( ///
Gəlin bu interfeysi həyata keçirək. Yaradılan üsullar və xüsusiyyətlər olduqca sadədir. Onlar sadəcə sorğunu sistemdə istədiyiniz obyektə yönləndirirlər. Buna görə də, qısalıq üçün yuxarıdakı kodu qısaldacağıq. Gəlin yalnız konstruktoru və hər birinə bir xassə və bir metod buraxaq.
İctimai sinif BlogEditorFacade: IBlogEditorFacade ( şəxsi BlogEditor _blogEditor; ///
Sinif konstruktoru Fasadın girişi təmin etməli olduğu sistem nümunəsini təyin edir. Müştəri kodu indi daha asan giriş üçün interfeysdən istifadə edə bilər:
İctimai sinif blogylitori Əgər (isPostValid) ( this._blogEditor.Publish(); ) isPostValid qaytarır; ) ) məzmunu təsdiq edin
İstifadəsi BlogClient göstərildiyi kimi:
BlogEditor blogEditorObject = new BlogEditor(); /// ... BlogClient blogClient = yeni BlogClient(yeni BlogEditorFacade(blogEditorObject));
Nəzərə alın ki, interfeys Fasad konstruktoruna ötürülür. Bundan əlavə, sistem obyekti yaratmaq ( BlogRedaktoru) şablon tətbiqindən silindi.
Beləliklə, müştəri sistemlə işləmək üçün yalnız onun üçün yaradılmış interfeysdən istifadə edir. Şablon tətbiqinin sistemin tətbiqindən asılılığı da azaldılıb. Axı surət əvəzinə BlogRedaktoru onun nəslindən hər hansı birinə keçə bilər.
Bununla belə, bəzi hallarda şablonun özündə obyekt yaratmaq daha sərfəlidir. Məsələn, Fasadın hər bir nümunəsində sistemin öz nümunəsi var və ya lazım gələrsə, istifadə olunan sistemi müştərilərdən gizlətmək üçün.
Baxılan nümunəyə qayıdaraq qeyd etmək olar ki, sistemlə qarşılıqlı əlaqə daha asanlaşıb. Onun obyektlərinin metodlarının və metod çağırışlarının sayı azalıb. Şablondan istifadə məqsədinə nail olundu.
