4 ms·
Java was full of AbstractSingletonBeanFactory classes long before unit testing became a thing, or at least before it was a widespread. I think IOC containers ac
by flukus 6y ago
Java was full of AbstractSingletonBeanFactory classes long before unit testing became a thing, or at least before it was a widespread. I think IOC containers actually helped eliminate many of these abstraction overall, you need many less singletons and factories.
> intercept and rewrite code at execution time
I think "execution time" is one of the big issues, a lot of these patterns evolved from application server middleware like glassfish that would introspect and run packages and often provide services at runtime, sun and IBM were busy selling licenses and support for these applications servers so these abstractions were great for their bottom line.
Take away the execution time requirement and injects mocks/fakes/stubs at compile time suddenly you don't need interfaces to make mocking easier, static methods are easy to mock and you probably don't need DI/IOC.
- cobbzilla 6y ago> Java was full of AbstractSingletonBeanFactory classes long before unit testing became a thing You're right that Java had some long class names to start with, but I think it was mostly Spring that introduced the PerhapsOverlyDetailedClassNamingConvention. Spring's introduction and subsequent wide adoption was a big driver of TDD's growth, which encouraged all those interfaces and mocks.
- watwut 6y agoHonestly, I like long names style of java. I dislike the code style where everyone is using shortcuts for everything.
- cobbzilla 6y agoI don't mind them if they're not too long. And if you can use more recent version of Java, the new `var` keyword is a nice verbosity reduction.
- hibbelig 6y agoI think the point of AbstractSingletonBeanFactory is not the length of the name, but what it does. More specifically, on how meta it is what it does. You can have a bean. Great. You can have a bean that's a singleton. Also great. Then you discover that you can have two different beans that are singletons, and you find that they have one thing in common: how the single instance is created and accessed. Each such singleton bean will have about five lines of code that deal with the single instance, and these five lines will be largely similar. So the Enterprise Java Architect sees that there is something to be abstracted, goes to town, and now you can have seven lines of code configuring the abstraction, so that you can avoid writing the five lines of boilerplate. Unfortunately, the seven lines of configuration will be largely similar for different singleton beans...
- cesarb 6y agoAt this point, I must post the classic "Why I Hate Frameworks" rant: https://web.archive.org/web/20130430052914/http://discuss.joelonsoftware.com:80/?joel.3.219431.12 https://web.archive.org/web/20130430052914/http://discuss.jo...