Un alt aspect important al moștenirii este că poate fi dăunător: moștenirea poate distruge încapsularea și întotdeauna întărește conectivitatea. Cu siguranță, toată lumea este de acord că încapsularea este cel mai fundamental și mai important concept orientat spre obiect.
Dacă da, atunci de ce o distrugem? În cazul în care încapsulare tipul de suport de bază a protejat câmpuri, și încălcați integritatea cojii de încapsulare și deschide interiorul clasei de bază, nu poate fi bun. Mai jos sunt considerate alternative disponibile care vă permit să dezvoltați un design mai bun.
Mulți descriu moștenirea drept o reutilizare a tipului de "cutie albă". Cea mai bună formă de reutilizare este "cutia neagră" atunci când interiorul obiectului nu se deschide pentru lumea exterioară. Acest lucru poate fi realizat prin aplicarea unei relații de izolare. Da, așa este.
În loc să moșteni o clasă nouă de la alta, puteți include o instanță a acestei alte clase în clasa nou creată, reutilizând astfel clasa de tip inclus fără a întrerupe încapsularea. Dezavantajul acestei tehnici este că în majoritatea limbilor, inclusiv C #, acest lucru va necesita un pic mai mult de codificare, deși nu prea mult. Dar rezultatul este un design mai adaptabil.
Ca un exemplu simplu, luați în considerare o zonă în care clasa servește unor tipuri de comunicații speciale în rețea.
Să numim această clasă NetworkCommunicator și să presupunem că arată astfel:
Acum, să presupunem că mai târziu a decis că ar fi frumos să aibă obiect EncryptedNetworkCommunicator în care datele sunt criptate înainte de a fi trimise. O abordare comună - să moștenească de la EncryptedNetworkCommunicator NetworkCommunicator.
Apoi implementarea ar putea arăta astfel:
Există un mare dezavantaj cu această opțiune. În primul rând, un design bun necesită ca pentru a modifica funcționalitatea metodelor din clasa de bază, ele trebuie redefinite.
Pentru a le înlocui în mod corespunzător, acestea ar trebui imediat declarate ca fiind virtuale. Acest lucru va necesita o previziune a viitorului la proiectarea de clasă și de marcare metode NetworkCommunicator modificator virtual, dar din moment ce nu a fost posibil de a prezice viitorul, metodele nu au fost marcate ca virtual și, prin urmare, codul EncryptedNetworkCommunicator nu va compila de mai sus.
Da, în metodele C # pot fi ascunse prin utilizarea noului cuvânt cheie atunci când se definesc metodele clasei derivate. Dar dacă faceți acest lucru, atunci principiul conform căruia moștenirea modelează relația "este" (este-a) va fi încălcată.
Acum ia în considerare situația cu includerea:
După cum puteți vedea, lucrarea nu este mult mai mare. Dar plusul este că Communicator de rețea poate fi reutilizat, ca și cum ar fi o "cutie neagră". Dezvoltatorii NetworkCommunicator ar putea face sigilarea, dar ați putea să o utilizați din nou. Dacă ar fi pecetluit, prin definiție nu ai fi putut să moșteni de la el.
Utilizarea NetworkCommunicator prin includerea poate oferi chiar și un contract de achiziții publice pentru container, care va arăta diferit de cel care se vinde NetworkCommunicator. Această abordare este cunoscută ca modelul de proiectare a fațadelor.
Un alt dezavantaj al folosirii moștenirii este că nu este dinamic. Moștenirea este statică datorită faptului că este determinată în etapa de compilare. Această stare de lucruri poate fi, cel puțin, foarte restrictivă. Aplicând includerea, eliminați această restricție. Cu toate acestea, pentru a face acest lucru, ar trebui, de asemenea, să obțineți sprijinul unui prieten bun - polimorfism. Tipul inclus poate fi, de exemplu, un tip de interfață.
Dacă implementați acest algoritm ca implicit include tipul care poate înlocui în timpul rulării, apoi, dacă este necesar zona de subiect, o puteți înlocui întotdeauna cu propriile sale algoritmi speciali de sortare - atâta timp cât noul obiect algoritm de sortare implementează interfața necesară, de așteptat tipul containerului. Această tehnică este cunoscută sub numele de strategia de proiectare strategică (Strategie).
Ca rezultat, designul cu design dinamic este mult mai flexibil decât utilizarea modelelor statice. Aceasta include preferința pentru includerea moștenirii în multe cazuri de reutilizare. Acest tip de reutilizare este cunoscut sub numele de delegare, deoarece lucrarea este delegată la tipul inclus. Activarea previne, de asemenea, încapsularea, în timp ce moștenirea o distruge. Cu toate acestea, este important să faceți un avertisment.
Ca și în cazul oricărei tehnici, există riscul de supraîncărcare cu incluziune. Pentru clasele de servicii mici, s-ar putea să nu merită prea mult efort pentru implementarea includerii.
În unele cazuri, este necesar să se folosească moștenirea pentru implementarea specializării. Dar, vorbind în general, designul, care preferă incluziunea moștenirii ca un mecanism de reutilizare, oferă mult mai multă flexibilitate și este mult mai probabil să reziste testului timpului.
Luați întotdeauna în considerare puterea moștenirii, inclusiv eventualele consecințe neplăcute ale abuzului.
Trimiteți-le prietenilor: