Veidojot lietojumprogrammu, jums bieži būs jāizmanto saskarnes un abstraktas klases. Šajā rakstā ir aplūkoti daži izplatīti “saskarnes ļaunprātīgas izmantošanas” piemēri un stratēģijas, kuras mēs varam izmantot, lai no tām izvairītos. Tajā arī tiek apspriests, kas ir domāts ar principu “programma interfeisam, nevis ieviešanai”.
Kas ir saskarnes?
Pirmkārt, iepazīsimies ar saskarnēm un to, kāpēc tās nepieciešamas programmēšanā. Interfeiss ir stingri līgums; tam nav nekādas ieviešanas. Saskarne satur tikai dalībnieku deklarācijas. Jums var būt metožu deklarācijas, bet ne definīcijas. Interfeisā deklarētie locekļi jāievieš tipos (klasēs un struktūrās), kas paplašina vai ievieš saskarni. Interfeisā nedrīkst būt lauki. Saskarni nevar serizēt, jo tajā nevar būt datu biedru. Kā jau teicu, saskarnē var būt tikai deklarācijas, bet ne definīcijas.
Izvairieties no izmaiņām saskarnēs
Klasei vai struktūrai, kas paplašina saskarni, jāievieš visi tās dalībnieki. Ja ieviešana mainīsies, kods joprojām darbosies. Tomēr, ja mainās līgums, t.i., saskarne, jums būs jāmaina visu veidu interfeiss, kas paplašina saskarni. Citiem vārdiem sakot, jebkuras saskarnes izmaiņas ietekmēs visus veidus, kas paplašina interfeisu. Veidiem, kas paplašina saskarni, ir jāievēro līgums. Tātad, izmantojiet saskarnes tikai tad, kad tās reti jāmaina. Turklāt parasti ir labāk izveidot jaunu saskarni, nevis mainīt esošo.
Programma interfeisam, nevis ieviešanai
Iespējams, šad un tad esat dzirdējuši vārdus “programma interfeisam, nevis ieviešanai”. Jūs, iespējams, savā kodā izmantojāt saskarnes, bet jūs joprojām plānojāt ieviešanu. Tagad pārbaudīsim atšķirību starp abām pieejām.
Programmējot interfeisam, konkrētas ieviešanas vietā izmantojat visizplatītāko abstrakciju (saskarni vai abstraktu klasi). Tā kā saskarnes garantē vienveidību, programmēšana interfeisam nozīmē, ka ar līdzīgiem objektiem varat rīkoties vienādi. To darot, jūs esat atdalīts no ieviešanas - t.i., jūsu ieviešana var atšķirties. Tas piešķir elastību arī jūsu dizainam.
Šis koda fragments ilustrē saskarnes programmēšanu. Apsveriet interfeisu ar nosaukumu IRepository, kas satur dažu metožu deklarāciju. ProductRepository un CustomerRepository klases paplašina IRepository saskarni un ievieš metodes, kas deklarētas IRepository saskarnē, kā parādīts zemāk.
publiskā saskarne IR krātuve{
// Daži kodi
}
publiskā klase ProductRepository: IRepository
{
// Daži kodi
}
publiskā klase CustomerRepository: IRepository
{
// Daži kodi
}
Šo kodu var izmantot, lai izveidotu ProductRepository instanci.
IR krātuves krātuve = new ProductRepository ();
Ideja ir tāda, ka šeit varat izmantot jebkuru klasi, kas īsteno IRepository saskarni. Tātad arī šis apgalvojums ir derīgs.
IR krātuves krātuve = new CustomerRepository ();
Programmējot ieviešanu, šī vienveidība tiek zaudēta. Tā vietā jums parasti ir daži konstruktīvi, piemēram, “if..else” vai “switch..case” priekšraksti, lai kontrolētu koda uzvedību.
Izvairieties no saskarņu pārmērīgas izmantošanas
Katras klases saistīšana ar saskarni nav laba prakse. Pārmērīga interfeisu izmantošana šādā veidā rada nevajadzīgu sarežģītību, ievieš koda dublēšanos, pārkāpj YAGNI un samazina kodu bāzes lasāmību un uzturamību. Saskarnes tiek izmantotas, lai grupētu objektus, kuriem ir identiska uzvedība. Ja objektiem nav identiskas darbības, šī grupēšana nav nepieciešama. Saskarņu izmantošana, ja jums nebūs vairākkārtēju to ieviešanu, ir saskarnes pārmērīgas izmantošanas piemērs.
Interfeisa izveide klasei, kas atbilst klases publiskajiem dalībniekiem, ir diezgan izplatīta. To darot, jūs vispār nepievienojat nekādu vērtību - jūs vienkārši dublējat klases saskarni, nepievienojot reālu abstrakciju.
Tagad aplūkosim saskarņu pārmērīgas izmantošanas piemēru. Apsveriet šo interfeisu ar nosaukumu IProduct.
publiskās saskarnes IPprodukts{
int Id {get; komplekts; }
virkne ProductName {get; komplekts; }
dubultā Cena {get; komplekts; }
int Daudzums {get; komplekts; }
}
Produktu klase paplašina IProduct saskarni, kā parādīts zemāk.
publikas klase Produkts: IProduct{
public int Id {get; komplekts; }
publiskā virkne ProductName {get; komplekts; }
publiska dubultā Cena {get; komplekts; }
public int Daudzums {get; komplekts; }
}
Skaidrs, ka mums nav nepieciešama IProduct saskarne, jo interfeiss un tā ieviešana ir identiski. Liekais kods nav vajadzīgs.
Apskatīsim citu piemēru. Šis koda fragments parāda interfeisu ar nosaukumu IProductManager, kuram ir divu metožu deklarācija, proti, Saglabāt un Atjaunināt.
publiskā saskarne IProductManager{
void Save (IProduct produkts);
void Update (IProduct produkts);
}
Interfeiss IProductManager satur klases ProductManager publisko metožu deklarācijas. Lūk, kā izskatās klase ProductManager.
publiskā klase ProductManager: IProductManager{
public void Save (IProduct produkts)
{
// Uzrakstiet savu ieviešanu šeit
}
public void Update (IProduct produkts)
{
// Uzrakstiet savu ieviešanu šeit
}
}
Interfeisi IProduct un IProductManager ir saskarnes pārmērīgas izmantošanas piemēri. Abām šīm saskarnēm ir viena ieviešana, un tās vispār nepievieno nekādu vērtību.
Izmantojot saskarnes, jūs varat noņemt nevajadzīgos savienojumus savā kodā un padarīt kodu viegli pārbaudāmu. Tomēr jāizvairās no saskarņu pārmērīgas izmantošanas. Izmantojiet saskarnes tikai tad, kad tās būs vairāk nekā viena. Varat arī izmantot saskarnes, ja jums ir klase, kurai ir daudz lomu vai kurai ir vairāki pienākumi. Šajā gadījumā jūsu klase var ieviest vairākas saskarnes - vienu katrai lomai.
