Unde verifici ca acel stepSize este diferit de 0? sau de unde ar trebui eu sa stiu asta. Daca acest parametru ar fi folosit peste tot in cod (mai multe functii etc) poti adauga un nou tip denumit NonZeroDouble iar semnatura metodei tale ar fi:
inline static double GetMaxRadiusIndex(double E, size_t maxIndex, NonZeroDouble stepSize)
Care este destul de specific, din care inteleg ca acea valoare nu poate fi 0.
Note: Sper ca atat tu cat si oricine altcineva citeste aici sa ia aceasta discutie ca una costructiva si nu ca o cearta pe principii.
De fapt, se preteaza beton la o programare multi-paradigma, obiecte precum vector, matrice, tensor, etc… sunt foarte utile.
stepSize in mod tipic e calculat. Nu e introdus de catre utilizator. In cazul asta particular, stepSize nici macar nu e calculat, ci e 1. Pur si simplu. E o chestie un pic mai complicata, cu grid ne-uniform.
Sper ca nu-mi spui sa mai adaug o clasa pentru valoarea 1, ca ar fi chiar amuzant.
Ai aici un exemplu unde numerele cuantice sunt impachetate in obiecte:
Se poate vedea la linia 115. De ce? Nu sunt doar pasate ca parametri, sunt folosite la mai mult decat atat (de exemplu, ceva iterare mai complicata, obiectele alea fiind si iteratori).
De fapt, sunt mai multe. Si daca o sa sapi un pic pe acolo, o sa constati ca impachetarea in structuri nu e facuta doar pentru ca sa se paseze impachetat la un singur apel de functie.
Discutia incepuse bine, dar a luat o directie nu tocmai constructiva pentru ca unii insista pe detalii specifice unei probleme anume sau pe un limbaj de programare anume.
Ideea de a impacheta uneori parametri unei functii intr-o clasa/structura/whatever nu e inventata de ieri de azi, sau de OOP, ci este imprumutata din viata reala. OOP a aparut pentru a modela lumea reala.
Ce rol are programarea in esenta? Sa modeleze un sistem real.
Programarea nu poate sa cuprinda un sistem real in esenta lui, ci creeaza a aproximare a sistemului real, un model. Cu cat modelul reprezinta o aproximare cat mai buna a spatiului problemei respective, cu atat programul respectiv (solutia problemei) este mai bun.
Asa ca atunci cand un programator decide sa inlocuiasca 2, 3, 4 sau 10 parametri cu o clasa/structura, o face (sau ar trebui s-o faca) avand in minte domeniul real pentru care scrie programul respectiv. Nu inventeaza o clasa doar de dragul de-a o face, ci foloseste o aproximare a unui lucru real din domeniul respectiv.
De exemplu, nu inventez clasa Point pentru ca mi-e lene sa trimit doua coordonate x si y de fiecare data cand am nevoie de un punct, ci pentru ca punctul inseamna mai mult decat doua coordonate in domeniul pentru care scriu programul respectiv. Poate coordonatele x si y au niste limite, poate punctul are “behavior” (metode). Totul depinde de domeniul pentru care scriu programul respectiv, totul depinde de context.
@anon31094663
Poate ma insel, dar pari foarte pornit impotriva claselor/structurilor de orice fel. Incearca sa scrii un program, de orice fel, folosind numai primitive si povesteste-ne apoi cum a fost.
Poate ca merge cand implementezi niste algoritmi matematici, desi am dubii mari si acolo. Dar gandeste-te ca foarte multe programe sunt mai “high-level”: web APIs, UIs, etc. Cum ar fi sa lucram intr-un program de genul asta numai cu primitive?
Te inseli
Si daca te uitai mai atent la discutie, iti dadeai seama.
Sau chiar la codul din exemple.
Sunt insa impotriva claselor facute cu orice scop, doar sa fie acolo, cat mai multe, pe criterii arbitrare.
Ai vazut-o pe aia cu coeficientii de mai sus? Poate fi extinsa ideea. E ceea ce sugeram. Hai sa zicem, mai bagam si AzimuthalQuantumNumbers,MagneticQuantumNumbers… sa fie acolo, la numar.
Ups, eu mi-am facut o regula ca pentru orice metoda care are 4 parametrii sau mai multi, sa-i prind intr-o clasa (daca au legatura unul cu altul) pentru a fi cat mai usor/rapid de citit.
