4) Jak bys v javě za běhu modifikoval třídu a všem stávajícím instancím změnil chování nějaké metody?
Javu moc dobře neznám. V C++ bych asi věděl. Přes věci jako dll injection se dají dělat zajímavé divočiny.
Daleko lepší nápad mi ale přijde, pokud má daný systém nějaké zotavení z pádu, kontrolovaně shodit celý proces a nahradit ho novou verzí.
Jedna možnost - reflexí.
Druhá možnost - něco kolem vzoru interpreter.
Záleží, jak bych to chtěl pojmout. Zda jako hack, nebo jako systém.
(Určitě existují další způsoby.)
Kdyz uz takovou potrebu, ze menim classes za chodu, vybec mam, je neco hodne spatne v architektonickem navrhu.
V realu tohhle vede leda tak k nedefinovanemu bordelu, protoze nedokazu zajistit, aby se objekt nemodifikoval v nejakem prechodovem stavu.
V Jave proto Spring Boot sestavuje aplikaci pri startu, classes kompozice se sestavi jako IoC assembly podle konfigurace, musi vsak splnovat interface, pres ktere to spring via @autowired slepi dohromady. Jak uz aplikace nabehne, do kodu se uz nehrabe, to je hovadina.
Obdobnou funkcionalitu muze poskytnou Java OSGi container, tam se ale za chodu nemeni jednotlive classes, ale services. Tam je mozne uhlidat konzistenci, vymeni se zkratka servica, coz je uplne jina immutable class se stejnym interfacem, stavajici runy zkratka dobehnou, servica se otoci s novou class a hotovo. Je to vlastne obdoba microservices v ramci JVM.
Ma to definovany lifecycle, ostatni spolupracujici servicy zpusobne pockaji, nez se moje servica otoci.
Mutace class za chodu, i kdyz to pres reflection api asi pujde, je tak leda gigabordel.
Dalsi aspekt, jak se ma zachovat serializace? Kdyz ponecham puvidni id serializace, tak lzu, a zpusobim tak leda pad JVM pri deserializaci. Kdyz mam id jine, coz spravne byt musi, je to defacto jina class.