[Java] return then reset

Torej, eno takšno vprašanje, ki je malo tehnično, malo pa je odvisno od osebnih preferenc oz berljivosti kode. Imam class, z boolean propertyjem in z "getterjem". Ta getter ni navaden getter, ampak naj bi vedno resetiral vrednost propertyja na neko hardkodirano vrednost. Lahko je pa tudi navaden getter, vendar potem je treba ročno klicati še reset oz set. Psevdokoda:

public class Abc {
  private boolean xyz;

  public Abc() {
    xyz = false;
  }

  public void narediNekaj() {
    // Tukaj naceloma nekaj procesiram in v dolocenih primerih se xyz nastavi na true.
    // Ne vedno.
    if(nek pogoj) {
      xyz = true;
    }
  }
}

Zdaj pa vprašanje, kako naredit getter in zakaj je bolje eno ali drugo:
Prvič:

public boolean isXyz() {
  boolean retVal = xyz;
  xyz = false;
  return retVal;
}

Drugič:

public boolean isXyz() {
  try {
    return xyz;
  } finally {
    xyz = false;
  }
}

Ali tretjič:

public boolean isXyz() {
  return this.xyz;
}

public resetXyz() {
  this.xyz = false;
}

Zadnji primer je sicer malo drugačen, ker moraš vedet, da je treba vedno klicat tudi reset. Po drugi strani pa ti omogoča več fleksibilnosti, če včasih nočeš imet resetirane vrednosti (zaenkrat takšnega primera še nimam). Seveda je možnost tudi kombinacija primera 3 + primer 1 ali 2 kjer seveda namesto "getterja" narediš metodo getAndReset() ali nekaj takšnega.

V glavnem, kateri primer, predvsem med 1 in 2 se vam zdi najboljši in zakaj. Je sploh pomembno? Obstaja še kakšen (boljši) način?

mr_chai je 14. mar 2023 ob 13:13 izjavil:

Getter naj bo getter, brez side effects!!! Po glavi bi te tepu, da bi vidu to kodo, pa da si moj intern.

Samo tretji način je pravi način oziroma kar direktna mutacija znotraj metode narediNekaj().
Če funkcionalnosti resetXzy() še ne rabiš je ne implementiraj.

Ne, ne bi me tepu, ker bi te prijavil. In če nisi opazil, je getter v narekovajih, ravno zato, ker ne gre za čisti getter. Če dobro prebereš, sem omenil metodo getAndReset(), ki bi naredila to, kar želim.

Da pa ne boš preveč brihten, direktna mutacija znotraj metode narediNekaj ni mogoča, ker kasneje v programu moram vedet, če je bil flag nastavljen na true. In kadar ta flag preberem, ga moram nastavit nazaj na false. Zato bi bilo fajn, če obstaja metoda, da se ta flag resetira, ko ga preberem. Recimo z metodo getAndReset, da ne bomo govorili o čistih getterjih.

Torej, kako najbolje implementirati metodo getAndReset(). Prvi ali drugi primer? Ali kaj tretjega, na kar nisem pomislil?

Ok, nevermind. Admini lahko zaprete temo, ker očitno nihče ne razume, kaj sprašujem.

Hvala. getAndSet je to kar potrebujem, ampak zgornji "programerji" pravijo, da je to no-go. In to tako dobri "programerji", ki bi interne kar po glavi tepli. In to ponoči, v temi, ker pokazat se ne bi upali.

GupeM je 14. mar 2023 ob 16:15 izjavil:

Hvala. getAndSet je to kar potrebujem, ampak zgornji "programerji" pravijo, da je to no-go. In to tako dobri "programerji", ki bi interne kar po glavi tepli. In to ponoči, v temi, ker pokazat se ne bi upali.

Guci guci no...
Malo šale, nikarte tako resno tovariš.

GupeM je 14. mar 2023 ob 16:15 izjavil:

Hvala. getAndSet je to kar potrebujem, ampak zgornji "programerji" pravijo, da je to no-go. In to tako dobri "programerji", ki bi interne kar po glavi tepli. In to ponoči, v temi, ker pokazat se ne bi upali.

No go je iz razlogov. Sploh ko do iste spremenljivke dostopajo različni porabniki.

GupeM je 14. mar 2023 ob 13:38 izjavil:

mr_chai je 14. mar 2023 ob 13:13 izjavil:

Getter naj bo getter, brez side effects!!! Po glavi bi te tepu, da bi vidu to kodo, pa da si moj intern.

Samo tretji način je pravi način oziroma kar direktna mutacija znotraj metode narediNekaj().
Če funkcionalnosti resetXzy() še ne rabiš je ne implementiraj.

Ne, ne bi me tepu, ker bi te prijavil. In če nisi opazil, je getter v narekovajih, ravno zato, ker ne gre za čisti getter. Če dobro prebereš, sem omenil metodo getAndReset(), ki bi naredila to, kar želim.

Da pa ne boš preveč brihten, direktna mutacija znotraj metode narediNekaj ni mogoča, ker kasneje v programu moram vedet, če je bil flag nastavljen na true. In kadar ta flag preberem, ga moram nastavit nazaj na false. Zato bi bilo fajn, če obstaja metoda, da se ta flag resetira, ko ga preberem. Recimo z metodo getAndReset, da ne bomo govorili o čistih getterjih.

Torej, kako najbolje implementirati metodo getAndReset(). Prvi ali drugi primer? Ali kaj tretjega, na kar nisem pomislil?

Še premal sem reku, da bi te tepu. Sploh pa s takim pametnim jezikanjem nazaj ;)

Tudi ta tvoja getAndSet() metoda je neprimerna rešitev za to kar ti rabiš.
Zgleda kot strel v koleno, sploh če laufaš kodo v kakšnem concurrent kontekstu.

Tudi opis problema je zelo slab, če bi podal malo širši kontekst, bi se mogoče izkazalo, da obstaja bolj preprosta rešitev.

Kar sem uspel razvozlati iz tvojega teksta so sledeče zahteve:

- Rad bi izvedel, če je bil xyz predhodno nastavljen na true, ampak preprosto preverjanje z if (myobj.getXYZ()) mi ni dovolj cause reasons
- Če je trenutno xyz == true IN je bil predhodno nastavljen na true (očitno xzy field inicializiraš na true, cause reasons), šele potem ga daj nazaj na false

Ja potem preprosto lahko narediš še en boolean field kjer hraniš če je bil xyz premaknjen na true. Ampak pol maš še z resetiranjem tega nekaj dela. To mi zveni res po zahtevah sodeč en tak solution smell.

A slučajno pišeš parser ?

Obstaja še kakšen (boljši) način?

Obstaja. Da ti to compiler sploh ne dovoli.

GupeM je 14. mar 2023 ob 23:17 izjavil:

mr_chai je 14. mar 2023 ob 21:06 izjavil:

Še premal sem reku, da bi te tepu. Sploh pa s takim pametnim jezikanjem nazaj ;)

Spet pametuješ, pa še problema ne razumeš. Vse kar rabim je to, kar delata metodi v prvem in drugem primeru. Namesto isXyz(), si predstavljaj, da se imenujeta getAndResetXyz().

Zadeva ni concurrent, niti za to ni potrebe, niti ni namenjena, da bi bila.

Če bi bil vsaj četrt tako pameten, kot se delaš da si, bi iz primerov 1 in 2 lahko razvozlal, kaj je namen, četudi opis mogoče ni najboljši. Ker obe metodi delata isto, samo napisano je drugače. Pa si raje spil brihtol in povedal nič. No, saj... Naziv PNG vse pove.

Zimonem je 14. mar 2023 ob 21:38 izjavil:

Obstaja še kakšen (boljši) način?

Obstaja. Da ti to compiler sploh ne dovoli.

Še en z nazivom, pa bom vseeno vprašal:

Česa ti ne dovoli? Vsi trije primeri iz prvega posta delujejo.

Mislim, da ti samo še l manjka v nicku, ker si res GlupeM.

Sj na faksu boš verjetno zdelal tisto Programiranje 1, ampak pol ko boš enkrt v idustriji se boš plazu od firme do firme, ker te bo vsaka po testnem obdobju odpustila.

fido89 ti je linku na AtomicBoolean class, ki ima metodo z imenom getAndSet(), ampak tam je kontekst drugi, gre za specifičen concurrency pattern, konkretno za CAS(Compare and swap), ki ga vsi Atomic* classi implementirajo. Ti pa si zlorabu to ime. Nekdo ki bo gledal kodo za tabo, ki je bolj izkušenj bo na prvi pogled mislil, da je to neka atomic operacija. Če že hočeš to uporabit, spremeni tip xyz v AtomicBoolean in potem na njem kliči getAndSet() !!

Kar pojdi na github pa naredi text search v java codebaseih za "getAndSet", pa boš vidu, da se kličejo na objektih, ki imajo Atomic v imenu.

Ampak to kar ti hočeš nardit je simpl, sploh če že imaš getterja in setterja za xyz. Zakaj preprosto ne uporabiš getterja in setterja na tistem delu kode, ki uporablja ta objekt ?? Recimo da je ta tvoj getAndSet() poimenovan getValueAndSet(), da se izognemo dvoumnosti. Še vedno si s tem naredu eno stvar in to je, da se logika klicoče kode, ki uporablja ta objekt, preveč zliva v sam objekt. To pomeni, da si izgubil en nivo abstrakcije.

Sicer pa, briga mene...pojasnu sm ti, če si tolk glup da ne štekaš, pol itak nima veze.

Vecina tukaj se je zapicila v poimenovanje, ki namiguje, da je ta metoda getter. In getterji naj bi predstavljali stanje objekta, ne pa logike.

IMO (in sem videl ze ogromno dobre in slabe kode v Javi, Kotlinu in se marsicem) getAndResetXYZ(), getAndSetXYZ() ali getAndWhateverXYZ() dovolj dobro signalizirajo kaj se znotraj dogaja in da ne gre za nek osnovni getter, tako da v tem ne vidim nic spornega.

GupeM je 15. mar 2023 ob 06:11 izjavil:

Haha. Spet bluziš. Poglej, prosim, od kdaj sem član slo-techa, pa če se ti zdi, da sem primerno star za na faks. Pol se pa vpraš koga bi ti tepu.

Odstrani se iz te teme, ker nisi še ničesar pametnega povedal. Razen tega, da naj uporabim AtomicBoolean, če hočem uporabit njegovo metodo getAndSet. No fucking shit, Sherlock!!! Na raw type booleanu jo lahko ti uporabljaš. Si tako brihten, da ti bo verjetno uspelo.

Kot sem rekel, fido89 mi je dal odgovor z enim stavkom. Brez filozofiranja.

Ja očitno je stanje še slabše, kot sem mislil. Gre za odraslega retarda, ki mu ne manjka napuha.

Bog pomagaj tistemu, ki bo bral tvojo kodo. Upam, da ne bo nobenega, ki bi bral za tabo tvoja skropucala.

S svojim zadnjim stavkom si pa tudi dokazal, da res ne dojameš bistva. Niti tega kar ti je fido89 hotel povedati.

Kako ti sploh pade na pamet try finally za to uporabit. Holy shit. Finally bloki so za zapiranje resourcov.

Spura je 15. mar 2023 ob 12:39 izjavil:

Kako ti sploh pade na pamet try finally za to uporabit. Holy shit. Finally bloki so za zapiranje resourcov.

Ja? Kje pa to piše? V kakšnem zakonu?

Uradna Oracle dokumentacija za javo namreč pravi sledeče:

The finally block always executes when the try block exits. This ensures that the finally block is executed even if an unexpected exception occurs. But finally is useful for more than just exception handling — it allows the programmer to avoid having cleanup code accidentally bypassed by a return, continue, or break. Putting cleanup code in a finally block is always a good practice, even when no exceptions are anticipated.

Če mora bit flag nastavljen na false po tem ko si ga uporabil, je to cleanup code, ane?

Ob pogledu na implementacijo AtomicBoolean.getAndSet(boolean) iz JDK 1.7 (menda), bi jih verjetno kar kap ruknila.