Video: Building Dynamic Web Apps with Laravel by Eric Ouyang 2024
Conceptul de moștenire și deci factoring în C ++ permite unei clase să moștenească proprietățile unei clase de bază. Moștenirea are o serie de scopuri; beneficiul principal al moștenirii este capacitatea de a evidenția relația dintre clase. Aceasta este așa-numita relație IS_A - un cuptor cu microunde Oven IS_A și așa ceva.
Factoringul este un lucru minunat dacă faceți corelațiile corecte. De exemplu, relația cuptor cu microunde față de cuptorul convențional pare naturală. Afirmați că cuptorul cu microunde este un tip special de prăjitor de pâine și că vă îndreptați spre probleme. Adevărat, ambele fac lucruri fierbinți, ambele folosesc energie electrică și ambele găsesc în bucătărie, dar asemănarea se termină acolo - un cuptor cu microunde nu poate face toast și un prăjitor de pâine nu poate face nachos.
Identificarea claselor inerente unei probleme și trasarea relațiilor corecte între aceste clase este un proces cunoscut sub numele de factoring. (Cuvântul este legat de aritmetica pe care ați fost obligată să o faceți în clasa de învățământ: factoring-ul celor mai puțin numitori, de exemplu, 12 este egal cu 2 ori 2 ori 3.)
Iată cum puteți utiliza moștenire pentru a vă simplifica programele folosind un exemplu de cont bancar. Să presupunem că vi sa cerut să scrieți un program bancar simplu care a implementat conceptul de cont de economii și un cont de verificare.
Programatorii orientați spre obiect au venit cu un mod concis pentru a descrie punctele importante ale unei clase într-un desen. Clasele Checking și Savings sunt afișate în această figură. (Aceasta este doar una din mai multe modalități de exprimare grafică a aceluiași lucru.)
Pentru a citi această figură și celelalte figuri, rețineți următoarele:
-
Cutia mare este clasa, cu numele clasei din partea de sus.
-
Numele în cutii sunt funcții ale membrilor.
-
Numele care nu sunt în cutii sunt membri de date.
-
Numele care se extind parțial din cutii sunt membri accesibili publicului; adică acești membri pot fi accesați prin funcții care nu fac parte din clasă sau din oricare dintre descendenții acesteia. Membrii care se află complet în cutie nu sunt accesibili din afara clasei.
-
O săgeată groasă reprezintă relația IS_A.
-
O săgeată subțire reprezintă relația HAS_A.
O mașină IS_A Vehicul , dar o mașină HAS_A Motor .
În prima figură puteți vedea că clasele Checking și Savings au multe în comun. De exemplu, ambele clase au funcția de retragere () și depozit ().Deoarece cele două clase nu sunt identice, acestea trebuie să rămână ca clase separate. (Într-o aplicație bancară reală, cele două clase ar fi mult mai diferite decât în acest exemplu). Totuși, ar trebui să existe o modalitate de a evita această repetare.
Ai putea avea una din aceste clase să moștenească de la cealaltă. Economii are mai mulți membri decât Verificați, astfel încât să puteți lăsa Economii să moștenească de la Verificați. Acest aranjament este prezentat în următoarea figură.
Clasa Economii moștenește toți membrii. Clasa este completă cu adăugarea membrului de date noWithdrawals și prin suprimarea retragerii funcției () . Trebuie să ignorați retragerea () deoarece regulile de retragere a banilor dintr-un cont de economii sunt diferite de cele pentru retragerea banilor dintr-un cont de verificare.
Deși permițând Economii să moștenească de la Verificarea este salvarea muncii, nu este complet satisfăcătoare. Principala problemă este că, asemenea greutății enumerate pe permisul de conducere al meu, aceasta reprezintă greșit adevărul. Această relație de moștenire implică faptul că un cont de economii este un tip special de cont de verificare, care nu este.
Astfel de declarații false sunt confuze pentru programator, atât azi, cât și de mâine. Într-o zi, un programator care nu este familiar cu trucurile noastre de programare va trebui să citească și să înțeleagă ce face codul nostru. Înțelegerile înșelătoare sunt dificil de reconciliat și de înțeles.
În plus, astfel de declarații false pot duce la probleme pe drum. Să presupunem, de exemplu, că banca își modifică politicile în ceea ce privește verificarea conturilor. Spuneți că decide să perceapă o taxă de serviciu pentru verificarea conturilor numai dacă soldul minim scade sub valoarea dată în cursul lunii.
O schimbare ca aceasta poate fi ușor de manevrat, cu modificări minime la clasa Verificare. Va trebui să adăugați un nou membru de date la clasa Verificarea pentru a ține evidența soldului minim în timpul lunii. Să ieșim pe un membru și să-l numim minimumBalance.
Dar acum aveți o problemă. Deoarece Economii moștenește de la Verificarea, economiile primesc și acest nou membru de date. Nu are nici un folos pentru acest membru, deoarece soldul minim nu afectează conturile de economii, așa că este doar acolo. Rețineți că fiecare obiect de cont de verificare are acest membru suplimentar minimumBalanță . Un membru suplimentar de date nu poate fi o afacere mare, dar adaugă și mai multă confuzie.
Modificări de acest fel se acumulează. Astăzi este un membru de date suplimentar - mâine este o funcție de membru modificată. În cele din urmă, clasa de conturi de economii poartă o mulțime de bagaje suplimentare care se aplică numai conturilor de verificare.
Acum, banca revine și decide să modifice politica contului de economii. Aceasta necesită modificarea unei anumite funcții în Verificare. Modificările de acest gen din clasa de bază se propagă automat în jos până la subclasa, cu excepția cazului în care funcția este deja suprascrisă în subclasa Economii.
De exemplu, să presupunem că banca decide să dea toasterilor pentru fiecare depozit în contul de verificare. Fără a ști banca (sau programatorii săi), depozitele la conturile de verificare ar duce automat la donații de la toaster. Dacă nu sunteți foarte atent, modificările la Verificarea pot apărea în mod neașteptat în Economii.
Cum poți evita aceste probleme? Afirmând că Verificarea este un caz special de Economii modificări, dar nu ne rezolvă problema. Ceea ce aveți nevoie este o clasă a treia (apelați-l Cont, doar pentru a vă înfrunta) care întruchipează lucrurile care sunt comune între Verificați și Economii, .
Cum construiește un cont nou rezolva problemele? În primul rând, crearea unei noi clase Cont reprezintă o descriere mai exactă a lumii reale (oricare ar fi aceasta). Desigur, există într-adevăr ceva cunoscut ca un cont. Conturile de economii și conturile de verificare sunt cazuri speciale ale acestui concept mai fundamental.
În plus, clasa Economii este izolată de modificările aduse clasei Verificarea (și invers). Dacă banca instituie o modificare fundamentală a tuturor conturilor, puteți modifica Contul, și toate subclasele vor moșteni automat modificarea. Dar dacă banca își modifică politica numai pentru verificarea conturilor, puteți modifica doar clasa de cont Verificare fără a afecta Economii.
Acest proces de culegere a proprietăților comune din clase similare este esența factoringului de clasă .
Factoringul este legitim numai dacă relația de moștenire corespunde realității. Factoring împreună o clasă Mouse și Joystick , deoarece ambele dispozitive de indicare hardware este legitimă. Factoring împreună o clasă Mouse și Display , deoarece ambele fac apeluri de nivel scăzut de sistem de operare nu este.
