- PHP
- software-ul
- PLO
- Arhitectura aplicațiilor
Bună ziua. Când am dezvoltat un sistem, am întâlnit problema claselor de numire în cazuri complexe. Problema este că în ierarhia de clasă, un singur element nu are întotdeauna numai un "strămoș" (nu numai în sensul moștenirii ("floarea este moștenită de la plantă"), ci mai general "floarea are frunze"). De fapt, întrebarea este următoarea - care este regula pentru chemarea acestor elemente?
Câteva exemple de clase cu numele cărora apare problema (îmi cer scuze pentru exemplele stupide):
- Lily moștenit de la o floare (B, moștenit de la A)
- O petală care poate fi găsită numai într-un crin (C, care este folosit numai în B)
- O frunză care poate fi atât un crin, cât și o floare în general (D, care este folosit atât în B cât și în A)
- Un stâlp care poate fi atât un crin și un mac, dar nu are neapărat o floare (E, care este folosit și F (care la rândul său este moștenit de la A), și în B, dar în A nu este folosit )
Și un caz extrem: există un apartament, care are unele gunoi frumoase. Lily, în principiu, poate fi folosit ca un gunoi frumos. Cum pentru a numi adaptorul „Beautiful Lily ca gunoi“, așa că nu se pierde printre toate clasele (deoarece teoretic aparține grupului de „plat“, dar, de asemenea, depinde de „flori“ ale grupului)? În mod abstract - există un G care folosește H; cum să numesc I, ceea ce vă permite să utilizați B ca H?
Hitch apărut sistemul de fișiere strict ierarhic din cauza obiceiurilor și numesc clase de-la dosar (adică Fuston_Http_Response_Cookie_Marked). Acest obicei nu este doar răspunsul la întrebarea „ce să numim interfață, care va permite Testing_Database_Cache_Cookies să utilizeze în afara Fuston_Http_Response_Cookie clasa ca propriul Testing_Database_Cache_Cookies_Cookie?».
Moștenirea este doar cel mai mult că nici nu este un simplu, de exemplu, reflectă un răspuns abstract de răspuns, StaticResponse - răspuns, din care corpul este definit ca un șir de caractere, și DynamicResponse - răspuns, din care organismul este generat în momentul trimiterii răspunsului. Orice altceva nu este moștenit, ci numai utilizate (de exemplu, clasa de răspuns utilizează clase de obiecte Cookie pentru afișarea cookie-uri).
Interesat numindu-l, pentru că fără probleme. Pot să dau un exemplu concret, există EduPortal_Addon_Testing modul de testare cu o grămadă de clase și au un EduPortal_Application_Rating modul de rating, de asemenea, destul de ciudat, cu o grămadă de clase în interior. Vreau să adaug utilizarea funcției ca datele din clasamentul de testare. Am un rezumat în clasamentul datelor EduPortal_Application_Rating_Getter_Abstract beneficiare și destinatarul direct de la client EduPortal_Application_Rating_Getter_Wui. De obicei face acest lucru, creați un destinatar pentru modulul de testare, care este alimentat la obiectul pachetului EduPortal_Addon_Testing (dacă EduPortal_Addon_Testing_Core principal de cele mai multe, care va avea un API pentru a prelua date sau o clasă API specială pentru aceeași funcție). Ce ar trebui să numim acest destinatar (limbaj PHP)? EduPortal_Application_Rating_Getter_EduPortal_Addon_Testing? EduPortal_Application_Rating_Getter_EduPortalAddonTesting? EduPortal_Application_Rating_Getter_Testing? Acesta din urmă pare perfect, dar ce se întâmplă dacă există MathSite_Testing? Testarea depinde de ceea ce ultima destinație?
EduPortal_Application_Rating_Getter_Abstract este un nume ciudat. De ce adăugați Rezumatul la sfârșit, dacă clasa din semnătură are deja abstractitate? Nu știu cum sunteți acceptat în PHP, dar aș numi EduPortal_Application_Rating_BaseGetter.
Și receptorul de la Testing - el, cu excepția cazului în care nu aparține logic modulului Testing? Dacă da, de ce nu o puneți acolo și o numiți: EduPortal_Addon_Testing_RatingGetter?
Un nume ciudat este cauzat de autoloading clasei și dorința de a împinge clasele unei "regiuni" într-un singur director. În cazul dvs. și în standardele Zend, o clasă abstractă ar convoca mai bine fie _Getter sau _Getter_Abstract, deoarece fișierul BaseGetter.php și dosarul Getter arata prost unul la altul.
Asta este:
1. Numele clasei nu se va potrivi pe linie - este critic pentru codul sursă tipărit, iar citirea este ucisă
2. Este de așteptat întrebarea „SHOZANAH?“, Pentru acest șir lung de nimic nu spune unde se termină descrierea unei anumite clase (getter pentru rating) și începe să descrie parametrii (în cazul în care datele tyrit)
3. Deschiderea automată a claselor este lame - principiul obișnuit de "subliniere pe slash" nu este aplicabil datorită absurdității sale în acest caz, dar nu doriți să fiți inteligenți încă
Ei bine, în versiunea mea doar din cauza punctului 2 într-un singur loc există două subliniere - unde se termină numele complet al lui Getter și începe clasa asociată.
În general, încă mai cred că numele obișnuit ar fi:
EduPortal_Application_Rating_AddonTestingGetter, sau chiar mai bine, folosiți spațiul de nume.
Dacă aveți probleme tehnice și nu puteți face acest lucru - va trebui să suferiți cu linii lungi de neînțeles ... bine, motivul pentru a depăși problemele tehnice;)
1. Nu denumiți clasele Parent_it_etc
2. Utilizați spațiul de nume, acesta va scăpa de nume urât
3. Uită-te la numirea de clase în zend (pir), logica numelor de acolo vorbește de la sine
Dacă păstrați aceste trei puncte, nu veți fi niciodată pierduți =), iar numele vor fi frumoase, iar logica structurală va fi întotdeauna clară.
1. Acesta a fost motivul pentru această problemă (^_^) Răspuns Acolo, acolo DynamicResponse, moștenită de la răspuns și acolo ResponseCookie, care este utilizat de răspuns. Response_Dynamic and Response_Cookie - IMHO, prostie, pentru că descendent distins al helper de clasă nu poate fi fără un cod, dar alte delimitatori, cu excepția subliniere, nu (-_-).
2. Nu există niciunul, deși vreau (-_-) (a se vedea răspunsul anterior).
3. M-am uitat, acum o voi revizui și mai îndeaproape.
În Zend nici un adaptoare între componente din diferite sisteme, cum ar fi cadrul modulului, a unui alt modul al site-ului și propria sa unitate de proiectare, și mi-au încă nevoie (până când am venit cu o soluție mai bună) - A se vedea primul răspuns l-am dat un exemplu concret ..
/ bibliotecă
/ Responce /
/AbstractResponse.php
/Dinamic.php
/Cookie.php
Clasele vor fi numite aproximativ:
Responce_Dinamyc și Responce_Cookie
Aș fi făcut așa.
Și despre flori și petale, ai avut dreptate
/ Biblioteca /
/ Flori
/Petal.php
/Flower.php
Și clase în consecință:
Flower and Flower_Petal (aici logica nu este părintele - moștenitorul și raportul dintre obiect și subiect)
Aici e problema: Response_Dynamic moștenită de răspuns și nu Response_Cookie, ci dintr-o privire sumară, și fără ea nu se poate înțelege codul. Acest lucru ma determinat să pun o astfel de întrebare.