Ha szemantikai változásod van ... valójában az is API változás
Mit tekintünk annak? pl. egy triviális példa, egy User osztály email propertyje, aminek a dokumentációjában szerepel, hogy ha érvénytelen (elsőre legyen mondjuk RFC821-nek nem megfelelő), akkor dob egy IllegalArgumentException-t. Ha ezen felül bevezetsz egy új követelményt, hogy nem tartalmazhat + jelet a localpart (mert bár nem illik nézni, de így a leggyakoribb address extension karaktert kiszűrted), akkor az API változás?
A klienst nem kell módosítanod, mert az eddig is a User osztályodra bízta az érték validálását és eddig se tudott sok mindent kezdeni arral, hogy érvénytelen egy érték (miért volt érvénytelen? formai hibás? garantáltan nem létező [nincs se MX se A rekord (ez ugye mind a klienstől, mind a User mögött levő validálótól független!)]? egy dinamikusan változó feketelistán szerepel a domain part? visszajött egy bounce? ... ez mind belefér az "érvénytelen e-mail cím" definíciójába).
És akkor van-e különbség eközött a helyzet között és mondjuk aközött, hogy utólag mégiscsak beleteszel egy API-ba egy irányítószám-ellenőrzést, ahol eddig nem volt ("no-op setter"), csak annyi megkötés, hogy először az országot kell beállítani (pont azért, hogy később bele tudd tenni)? Ha az API leírásban korábban szerepelt, hogy dobhat kivételt, ha (biztosan) érvénytelen értéket kap a setZip, akkor volt-e szemantikai változás attól, hogy ezt elkezdted betartatni [akár csak néhány országra, ahol biztosan ismered a zip formátumot]?
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)