3 ms·
>I'd honestly prefer if it were just some crusty old Java monolith where all the objects are stateful, and have setters for every field, and all that good^H^H^H
by ImprobableTruth 6y ago
>I'd honestly prefer if it were just some crusty old Java monolith where all the objects are stateful, and have setters for every field, and all that good^H^H^H^H stuff. Because, while that kind of statefulness may not be well-isolated, it is navigable.
Am I getting this right? Your issue is a lot of hidden, opaque access to external state, so you think adding even more internal state on top would be a remedy because the stuff you add on top would be navigable?
- rembicilious 6y agoThat is what I gather as well. Really the parent wishes not to be interfacing with a database, and I suppose in dreamland the database could be integrated to the programmers IDE.
- disgruntledphd2 6y agoI get where they are coming from though. Even best case, a db call will add more latency than a getter/setter. They might also be missing the types (depending on what functional language it is). In general, I find that complicated systems with no owner (i.e. legacy systems) are much easier to understand if they're not constantly calling out to other systems like databases.
- mumblemumble 6y agoI think that the code I'm looking at took things that could have been internal state, and pushed them out to external state, and, ironically, ended up making them more hidden and opaque in the process. And I think that certain classes of old-school Java programs - specifically, the ones that use toolkits like Hibernate - have evolved a typical pattern for modeling external state that makes it relatively more navigable. The state tends to get proxied through these entity object horcruxes that aren't particularly well camouflaged.