Acum am citit cartea "Codul curat" și acum am decis să clarific de la dezvoltatori cu mai multă experiență decât am.
Aici este scris că trebuie să depuneți eforturi pentru a scrie funcții unare (care conțin un argument), dar este mai bine ca nimic să nu fie acceptat deloc, astfel încât este pur și simplu un nume frumos al funcției, după ce ați citit ce puteți înțelege intuitiv ceea ce face.
Dar, dacă nu mă înșel, aceasta este contrară regulilor de încapsulare. Înțeleg că puteți utiliza toate variabilele pe care funcția le utilizează pentru a le defini ca variabile globale, dar atunci această funcție va depinde sever de clasa în care este localizată. Și în acest caz va fi mult mai dificil să-l transferați în altă clasă.
În cazul ideal, numărul de argumente ale funcției este zero (o funcție null-ary). Apoi, există funcții cu un argument (unary) și cu două argumente (binare). Funcțiile cu trei argumente (ternare) ar trebui evitate ori de câte ori este posibil. Necesitatea funcțiilor cu mai multe argumente (poliarice) trebuie să fie susținută de argumente foarte înalte - și totuși este mai bine să nu folosiți astfel de funcții.
Mai mult, dacă citiți câteva pagini, acolo este descris mai profund și totul se reduce până la punctul în care funcțiile ar trebui în mod ideal să fie fără argumente.
Sau m-am înșelat?
Funcțiile cu parametrii de intrare nu sunt rele, însă trebuie să abordați cu atenție proiectul codului și să minimizați numărul de argumente.
Nu-mi amintesc dacă acest lucru este reflectat în carte sau nu, dar evita cazurile în care toate (mai multe) argumente ale funcției au același tip. Acest lucru duce deseori la erori.
Și totuși, variabilele globale sunt rele, despre care se scrie un milion de cărți.
Faptul de unaryness (sau mai degrabă chiar de a spune, atomicitate) de funcții și metode este una dintre cele la care este aproape imposibil să vină în 100% din cazuri în practică, dar la care, într-adevăr, este întotdeauna necesar să se străduiască.
Esența acestui sfat nu este aceea de a face ca toți parametrii să se globalizeze fără a se bloca, ci să ajungă la o soluție arhitecturală bună. Deoarece, dacă funcția / metoda / procedura / orice ia mai mult de 3-5 parametri pe intrare, aceasta, în majoritatea cazurilor, bate calitatea arhitecturii și indică lacune evidente în ea.
Încapsularea. Care este scopul principal al încapsulării? - pentru a forma o abstracție bună, pentru interacțiunea cu care trebuie să știți cât de puțin posibil detaliile implementării sale (în perfecțiune - nimic).
Comparați următoarele două seturi:
Care din seturi, în opinia dvs., dezvăluie detaliile implementării? Răspunsul corect este: în primul rând, deoarece ucide sensul de încapsulare ca atare.
Iar motivul pentru aceasta este redundanța, care apare ca urmare a unui număr mai mare de argumente ale constructorului 1.
Concluzie: cu cât mai puțini parametri pe care un subiect le iau de intrare, cu atât este mai bine încapsularea - parametrii dezvăluie detaliile implementării.
Pentru o înțelegere mai obiectivă a principiilor de proiectare a funcțiilor / metodelor. Vă sfătuiesc să citiți capitolul 7 din Codul perfect "Metode de înaltă calitate".
Această dorință rezultă direct din principiul unei taxe unice. Metoda, pe bune, trebuie să îndeplinească o sarcină unică, maximală atomică. Și vă asigur că vor exista foarte puține astfel de sarcini, pentru care veți avea nevoie de mai mult de doi parametri.
Unde sunt necesare mai mult - este logic să ne gândim la crearea unui obiect care are toate proprietățile / datele necesare și îl transferă.
Un exemplu nebun, de departe, dar care dezvăluie perfect esența.
Să presupunem că trebuie să creștem valoarea unei variabile cu una.
Opțiunea unu. Transmitem doi parametri funcției și atribuim rezultatul variabilei
Opțiunea doi. Trecem la funcția un argument, prin care schimbăm variabila.
A treia opțiune, ideală pentru o anumită sarcină atomică. Utilizăm o funcție fără argumente.
Din mine pot adăuga: Scrie funcții astfel încât să fie cât mai ușor de înțeles ce face - un titlu bun, primul lucru pe care trebuie să-l acordați atenție.
Fiecare funcție trebuie să îndeplinească o sarcină specifică numai pe un nivel de abstractizare - nu întrerupeți calculele la nivel inferior și codul de nivel înalt din interior.
Dacă trebuie să transmiteți mai mulți parametri, este mai ușor să faceți o clasă de argument - să obțineți o funcție unară.
În general, încercați să faceți funcția cât mai simplă posibil. Construirea unei tone de cod este foarte ușoară, la fel de confuză, dar rezolvarea problemei este pur și simplu mult mai dificilă.
De asemenea, ia în considerare sarcinile care sunt în fața dvs. Dacă este necesară viteza maximă, apelarea unei mulțimi de funcții în cadrul altor funcții poate avea un impact negativ asupra performanței aplicației, în special asupra funcțiilor recursive sau a funcțiilor cu lanțuri de apel lung.