11–20 of 68 posts
I think core java libraries are amazingly designed and a good part of why the language became popular. You won't find many FactoryFactories there, The land of c,c++ libraries that came before is incredibly fragmented, inconsistent and difficult to use by comparison, not to mention the documentation. Good lord the docs ;x.
- HttpServlet
- AbstractXmlWebMvcResultProcessingInterceptorAdapter
- MockJtaTransaction
While there is HttpServlet class, it is considered wrong, and 3rd option is considered correct :(
The key thing to keep in mind with generative models based on real data is that just because results were based on random generation doesn't mean they can't match something real.
It's the knee jerk reflex of decoupling everything, to the point that you have 80% configuration/wiring/setup vs 20% of code that actually does something useful.
Each extension point in the framework is represented by a couple of these classes to handle the layer of indirection. Maybe Spring should run a study and see which of their extension points is actually used, at all, or by more than x % of users, and then cut down all the useless ones. I'm not too familiar with Spring these days, but I'd expect that the vast majority of indirections isn't actually useful for anybody.
The other problem is that our mechanisms to introduce and handle these abstractions are too verbose. Each extension point spawns multiple classes where it's really just one little method that needs to be called instead of another block of code. That makes software systems extremely hard to understand and use, and the overall bloat does actually slow things down - if not in production, then in deployment, startup, and build.
It never hurts to study the masters in serious enterprise software: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
This is great but it brings up a serious question I've always had. Taken to the extreme, things like the single responsibility principal, the open closed principal, etc, result in messes like this. I've been wondering if anything has been written around a concrete methodology of doing OOP that doesn't naturally converge onto something like this, and why it happens.
Usually though, if you try to make the code clean and as small as possible while still allowing unit tests to be written, you normally hit a decent spot. YAGNI applies very heavily here too and it's often better to make the code less generic and refactor it later when required.
Some answers are not 100% right. I got: - HttpServlet - AbstractXmlWebMvcResultProcessingInterceptorAdapter - MockJtaTransaction While there is HttpServlet class, it is considered wrong, and 3rd option is considered correct :(
It never hurts to study the masters in serious enterprise software: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
This is great but it brings up a serious question I've always had. Taken to the extreme, things like the single responsibility principal, the open closed principal, etc, result in messes like this. I've been wondering if anything has been written around a concrete methodology of doing OOP that doesn't naturally converge onto something like this, and why it happens.
It's not surprising that a Markov chain could put together plausible sounding class names, because yeah, there are definitely patterns that class names fall into. What's surprising is that one third of the names it's showing me are actually real. I mean, "MetaMetaContextHierarchyConfig" actually exists?
> I mean, "MetaMetaContextHierarchyConfig" actually exists? Apparently. https://github.com/spring-projects/spring-framework/blob/mas... "Custom context hierarchy configuration annotation that is itself meta-annotated with MetaContextHierarchyConfig"
It never hurts to study the masters in serious enterprise software: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
This is great but it brings up a serious question I've always had. Taken to the extreme, things like the single responsibility principal, the open closed principal, etc, result in messes like this. I've been wondering if anything has been written around a concrete methodology of doing OOP that doesn't naturally converge onto something like this, and why it happens.
I think the problem is that OOP is automatically considered "virtuous", despite the context. There's nothing wrong with the single responsibility principle and what not, but there is something wrong with thinking that classes and objects are always the best way to approach a problem. Java ends up being the target of jokes because by forcing everything into classes/objects even when it doesn't make sense, it leads to cartooned versions of those ideas.