czy w #javascript w klasie jeśli chcę mieć gettery i settery to złą praktyką będzie jesli zamiast set i get użyję set...() i get...()? Wydaje mi sie ze to jest lepsze bo bez problemu moge miec setMichal() this.michal = bialek, a z set już tak nie zrobię i będę musiał wymyślać inne nazwy, które już tak dobrze nie oddadzą działania metody. Poza tym przeczytalem o taki artykul: https://nemisj.com/why-getterssetters-is-a-bad-idea-in-javascript/ co sadzicie? #programowanie
@NiepodlegleWybrzezeKlatkiSchodowej myślę że podawanie literówki jako głównego zagrożenia jakie niosą get/set to strasznie #!$%@? argument który można podpiąć pod wszystko :D
@iksdede: owszem można, ale zrobienie metody pozwala ci w choćby w łatwy sposób zweryfikować które miejsca kodzie grzebią ci w danym property (wystarczy postawić debugger w jednym miejscu. W przypadku zwykłego property trzeba się bawić z udawaniem settera/gettera w konsoli)
Niby mogą, ale nazywnie tych metod w ten sposób jest trochę mylące (ja bym je nazwał withSomething zamiast setSomething), btw akurat bo OP używa niemutowalnych klas ;)
#programowanie
@NiepodlegleWybrzezeKlatkiSchodowej myślę że podawanie literówki jako głównego zagrożenia jakie niosą get/set to strasznie #!$%@? argument który można podpiąć pod wszystko :D
myślę że wydajność to najlepszy argument przeciw, czytelność nie bo jest relatywna
https://jsperf.com/getter-setter-performance
po przeciwnej stronie:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/get#Smart_self-overwriting_lazy_getters
Komentarz usunięty przez moderatora
@maciej-caderek: co ma jedno z drugim, kto powiedział, że setField albo settery nie mogą zachowywać niemutowalności? ( ͡° ͜ʖ ͡°)