Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Yeah, that would be amusing if it was accurate. Only that's not what it does. It is actually a way of extending the bean creation part of the framework that produces singleton scoped proxy objects.

I'm curious: what would you name that class?



I can assure you I wouldn't name that class.

But honestly, I'm kidding around. I'm not arguing the class is silly, or poorly named. I bet it's perfectly named. I'm not arguing the author did a bad thing here, I'm sure he or she did something awesome. All I'm saying is that the context that makes writing that class description necessary is totally hilarious.

Let's just agree on that. It doesn't mean Java sucks or Spring sucks. Big complicated projects sometimes lead to pretty wacky situations and we ought to be able to laugh at them. I'm certainly not suggesting other languages don't have the same culdesacs of lunacy.. they totally all do. Can you imagine the number of times someone's posted "Everything that's wrong with Perl in one line of code" ?

I really don't see any reason to take this stuff so seriously.


The context makes it entirely appropriate. A FactoryBean allows you to construct complex objects, or construct objects Spring can't easily create itself (e.g. JndiFactoryBean). A ProxyFactoryBean builds Spring AOP proxy beans.

As it turns out, there was no need for the class as it has been deprecated. However, providing an abstract singleton scoped proxy factory bean is indeed convenient. If there was a need for a factory that creates AOP proxies then it would be very useful to have an abstract class that implements most of the methods for you, and create them with singleton scope. In that case, AbstractSingletonProxyFactoryBean is sensible.

It's a corner case. It was used by one class, but that was deprecated later, so this was deprecated as there wasn't really a need for the convenience class.

I take this lot of stuff seriously because I see a lot of ignorant pattern bashing by those who haven't taken the time to understand why patterns are very useful and potentially can make OOP code cleaner and easier to maintain.


For the record, I spent 10-12 years coding Java (the last 4 or so w/ Spring). Lots of OOP, lots of pattern based enterprisey big boy stuff. I definitely have a solid (but atrophying) understanding of the concepts. I get that they're the right way to do big Java apps. But Java makes implementing them fucking laborious. Back when that was all I knew, it seemed elegant and I was used to the scaffolding.. but the truth is that in a number of other languages the same patterns require so much less scaffolding and even thought, that we don't even notice them. They're a given.

I give my users vastly more value-per-line-of-code now than I ever did writing Java.

That said, I have nothing against Java or folks that enjoy doing it... but even when it was a language that I was knee deep in and stoked on, I was able to laugh at some of the shark-jumping complexity of these cartesian products of patterns that would arise.


That's sort of the point of the class in question: use it derive your own class an you've extended the Spring framework...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: