Java POJO / Groovy POGO ze specyficznym setterem

W rozwiązaniu, które tworzę będą powstawały coraz to nowe proste klasy typy "Data" mówiąc po Kotlinowemu

class Osoba {
    String imie
    String nazwisko
}

Klasy będą tworzone przez nieprofesjonalnych programistów, więc nie chcę komplikować (nawiasem mówiąc celowo drażnię językiem polskim)
Trzeba mi, aby wszystkie settery przybrały formę

void set_nazwisko(String s){
    if(nazwisko != s)
    {
        fireChanging()
        nazwisko = s;
        fireChange();
    }
}

Jak ktoś widzi inspirację modelami Swinga, to dobrze widzi.
Otwieram dyskusję :)

Szukam inspiracji, pomysłów.

• trochę to ma z programowania aspektowego / emitowania bytekodu / proxy
• pozwolić górnej klasie się skompilować, rozebrać ją przez refleksję, wygenerować źródła jej "cienia"
• j/w na gruncie Groovy Metaclass, wybitnie runtimowo (acz niechętnie)
• na modyfikację procesu kompilacji groovy jestem za cienki.

Można mutowanie przenieść poziom wyżej :

class Ref<T>(private var obj:T,
             private val beforeChange : (T)-> Unit = {},
             private  val afterChange: (T)-> Unit = {}){
    fun get() : T = obj

    fun updateAndGet( updateAction: (T)->T) : T {
        val newObj = updateAction(obj)
        if (newObj != obj){
            beforeChange(obj)
            obj = newObj
            afterChange(obj)
        }
        return  obj
    }

}

Jak zaczniesz to robić to zobaczysz, że jeszcze te change akcje są troche bez sensu - to kolejny krok.
Tak samo jak to, że Ref też może być niemutowalny - tego możesz już nie przeżyć :-)

jarekr000000 napisał(a):

Można mutowanie przenieść poziom wyżej :

Poziom wyżej, super pomysł. Nietrudno zgadnąć, ze te klasy będą żyły w pewnym mini kontenerze / frameworku (tfu, tfu)

Ustawiłem myślenie w kręćku, coś takiego mi cicho pikało, chciało się do mnie dostać, ale nie podejmowałem.
Dlaczego "trochę bez sensu" jeszcze do mnie nie dociera, ale całe życie przed nami.

Piję druga kawę, może Polyglot mi się włączy ;)

Jeśli chodzi o te funkcje to IMO lepsze by były gdyby to było coś w stylu:

class Ref<T>(private var obj:T,
             private val onChange : (T,T)-> T = {before, after -> after}){
    fun get() : T = obj

    fun updateAndGet( updateAction: (T)->T) : T {
        val newObj = updateAction(obj)
        obj = if (newObj != obj){
            onChange(obj, newObj)
        } else {
            obj
        }
        return  obj
    }

}

(czyli można przyblokować zmianę, albo coś po niej dodać)