Lehet vele, Pl. ha read-only property-t akarok akkor nem írom meg a settert és máris csak olvasni lehet. De lehet mást is csinálni, Pl. ha egy adott tulajdonságnak olyan értéket adok amit nem vehet fel, akkor értékadáskor dobhat egy szép nagy exception-t. De eleve, ha belegondolsz Pl. egy label objektum ott figyel a formon. Neki van egy text tulajdonsága, ő egy string, azt a feliratot jelképezi ami rá van írva a címkére. Logikusan ő egy text mező lenne a Label objektumba, és a Label1 nevű címkéd feliratát úgy tudod „helló világ”-ra állítani hogy label1.Text=”helló világ”. Merthogy az az ő felirata. Az hogy a label objektumon belül mi zajlik lényegtelen, számodra fekete doboz, neked arra van szükséged hogy ha megváltoztatod a Text mező értékét akkor az legyen a felirat. Igen ám, csakhogy ha nincs property-d, akkor a mező értékének változásáról az objektum nem értesül, azaz a Text mezőt fölülírhatod, de ettől a képernyőn a felirat nem fog megváltozni csak ha ez után kiadsz egy újrarajzolást forszírozó függvényhívást is. Nos, erre találták ki a javások a getter/setter függvényt ami valóban gányolás, hiszen az objektumban valójában mezőként szereplő dolgot  függvényeken keresztül piszkálgatom csak azért hogy az objektum értesülhessen arról hogy változott az értéke. Plusz, hogy még szebb legyen, ha megnézed egy vizuális designerben a label objektumot ott már a Label-nek adsz értéket a Netbeans-ban a propety editorral (miközben a labelednek nincs Text propertyje, sőt a nyelvben sincs property). Persze messze nem ez a legborzasztóbb dolog amivel programozási témakörben találkoztam, egy vizuálbézikhez ez még mindig egy álom, nem is beszélve az RPG-ről, a COBOL-ról, a 6502-es assemblyről, csak 2007-ben azért annyira nem elegáns. Elvben egyébként valóban lehetne property-hez hasonló dolgot utólag is kreálni egy nyelvben, azaz az objektum kiértesítse a tulaj objektumot hogy változott a helyzet, csak ehhez operator overloading kellene, ez pedig a javából szintén kimaradt.
És persze a dolog nem csak vizuális osztályoknál érdekes, normál osztály esetén is jól jöhet ha az osztály értesül arról hogy egy mezője változott vagy ha algoritmus alapján tudom kiszámolni az értékét. Pl. jó kis cache kezeléseket lehet így csinálni (a getter vagy lerántja a szerverről az adatot vagy ha már megtörtént akkor a lokális értéket szedi elő) és még kismillió más dolgot – úgy hogy az osztályt használó program nem is tudja hogy belül mit csinál a rendszer. Nem is kell tudnia, nem az ő dolga. Tudod: egységbezárás… Neki azt kell tudnia hogy annak a mezőnek az értéke ezt és ezt tartalmazza. Az hogy az objektum ezt hogy reprezentálja belül az nem az ő dolga. Míg a getter/setter eleve függvényhívást feltételez – azaz rontja az egységbezárást. Legalábbis szvsz.
Ez így világos, de: ha egy értéket akarsz megváltoztatni, akkor simán public változó, ha meg mást is akarsz csinálni, akkor pedig függvény. Szerintem ez így logikus(abb). Megértettem, hogy mi az a property, de nekem abba a kategóriába kerül, hogy „ha van, akkor használom, ha nincsen, akkor nem hiányzik”.