Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy
stackoverflow.com
stackoverflow.com
The only bit about this that even strikes me as a little bit unreasonable is the "Proxy" bit at the end. Not sure why you need another level of Proxy on top of TransactionAwarePersistenceManagerFactory, but it's not like you type that name particularly often. Most likely it's referenced once in a Spring config file somewhere, and given a bean name of "persistenceManagerFactory" which is what would be referenced in code once at most. Hell, probably not even that... that's probably wired into another bean that just gives you the PersistenceManager... which you might not actually ever reference in code either, since Spring can auto generate JPA implementation classes that use JPQL queries, etc., and eliminate the need for most hand coding of anything JPA related.
OK, sure, just to look at it, at first blush, the name looks long and silly, but when you actually think about what it is and how it's used, it's not exactly a big deal.
At which point I bring you the story of the king's toaster [1] (which is a cautionary tale, not an aspirational story, just in case that should be unclear to anybody).
------------------------------------------------
Once upon a time, in a kingdom not far from here, a king summoned two of his advisors for a test. He showed them both a shiny metal box with two slots in the top, a control knob and a lever. "What do you think this is?"
One advisor, an engineer, answered first. "It is a toaster," he said.
The king asked, "How would you design an embedded computer for it?"
The engineer replied, "Using a four-bit microcontroller, I would write a simple program that reads the darkness knob and quantizes its position to one of 16 shades of darkness, from snow white to coal black. The program would use that darkness level as the index to a 16-element table of initial timer values. Then it would turn on the heating elements and start the timer with the initial value selected from the table. At the end of the time delay, it would turn off the heat and pop up the toast. Come back next week, and I'll show you a working prototype."
The second advisor, a computer scientist, immediately recognized the danger of such short-sighted thinking. He said, "Toasters don't just turn bread into toast, they are also used to warm frozen waffles. What you see before you is really a breakfast food cooker. As the subjects of your kingdom become more sophisticated, they will demand more capabilities. They will need a breakfast food cooker that can also cook sausage, fry bacon, and make scrambled eggs. A toaster that only makes toast will soon be obsolete. If we don't look to the future, we will have to completely redesign the toaster in just a few years.
With this in mind, we can formulate a more intelligent solution to the problem. First, create a class of breakfast foods. Specialize this class into subclasses: grains, pork and poultry. The specialization process should be repeated with grains divided into toast, muffins, pancakes and waffles; pork divided into sausage, links and bacon; and poultry divided into scrambled eggs, hard-boiled eggs, poached eggs, fried eggs, and various omelet classes.
The ham and cheese omelet class is worth special attention because it must inherit characteristics from the pork, dairy and poultry classes. Thus, we see that the problem cannot be properly solved without multiple inheritance. At run time, the program must create the proper object and send a message to the object that says, 'Cook yourself'. The semantics of this message depend, of course, on the kind of object, so they have a different meaning to a piece of toast than to scrambled eggs.
Reviewing the process so far, we see that the analysis phase has revealed that the primary requirement is to cook any kind of breakfast food. In the design phase, we have discovered some derived requirements. Specifically, we need an object-oriented language with multiple inheritance. Of course, users don't want the eggs to get cold while the bacon is frying, so concurrent processing is required, too.
We must not forget the user interface. The lever that lowers the food lacks versatility and the darkness knob is confusing. Users won't buy the product unless it has a user-friendly, graphical interface.
When the breakfast cooker is plugged in, users should see a cowboy boot on the screen. Users click on it and the message 'Booting UNIX v. 8.3' appears on the screen. (UNIX 8.3 should be out by the time the product gets to the market.) Users can pull down a menu and click on the foods they want to cook.
Having made the wise decision of specifying the software first in the design phase, all that remains is to pick an adequate hardware platform for the implementation phase. An Intel 80386 with 8MB of memory, a 30MB hard disk and a VGA monitor should be sufficient. If you select a multitasking, object oriented language that supports multiple inheritance and has a built-in GUI, writing the program will be a snap. (Imagine the difficulty we would have had if we had foolishly allowed a hardware-first design strategy to lock us into a four-bit microcontroller!)."
The king had the computer scientist thrown in the moat, and they all lived happily ever after.
See what I said below about how much I prefer JPQL and Spring Data... Personally, I really do not have a problem with this.
And yet some very complex solutions were solved with very simple languages, before Java was conceived.
So we're stuck with these complicated compile-time rules for defining everything in terms of a procedural language. We come up with complicated templates and generics for getting one set of methods to work with two types of data. Objects are needlessly serialized and deserialized to pass between systems, and programmers are needlessly spending time writing such methods.
I'm surprised that scala's paradigm of having actors work on data hasn't caught on more. When you separate them from the start, new modules are way easier to right, and integration time drops to near zero.
Or more accurately, the problem is that Java was a new language shoehorned into being "like" a language that was never meant to hold the concepts that Java demands. In some cases this manifests itself in more syntactical ways; C's pragmatic but unsophisticated approach typing works well for C, but starts to become a real burden when you start adding more sophisticated concepts onto the language. (Were generics really a concept that were ever appropriate for something like C? Generics deserve a more considered treatment; a language with structure and syntax designed with them in mind.) In other cases the impact is more clear but inexplicable; "In Java Everything is an Object"(tm)... except for the things that are not.
The end result is a language that is ugly and clumsy to work with without some pretty advanced tooling, all for reasons that really have no business being real problems. Shameful (primarily cosmetic) flaws forced upon Java by the business decision: "make it reminiscent of C".
I have the same complaint about C++. Had Java and C++ not burdened themselves with the design requirement of looking like C, they would be much better languages. Languages that stray further from the mold, like Scala or Go (I am thinking particularly of their abandonment of C inspired defines, in favor of a more Pascal approach), are more pleasant to work with for it. Perhaps this damages adoption.. but that is another matter I think.
The same could be said about Ruby and it's relationship to Perl and Python. It has cultural roots in those languages, but is often regarded to be better rather than worse. (As a die-hard Perl developer I disagree, but I don't hold a grudge.) All three are also considered to be C-like languages too, and they don't suffer the problems Java has.
One could argue that Java's problem was that it was designed for programming VCRs, DVD players, and Cable-TV boxes, and similar equipment, but the got stretched and pulled into environments it just wasn't ready for. That, plus Sun's hyper-aggressive marketing machine to turn Java into the language-for-everything, created the beast that it has become.
My personal view is that Sun turned Java into a programming language for charge-by-the-hour consultants. The culture of over-engineering exists because it takes a lot more time to design software that way, more time and larger teams to implement software that way, and specialized hard-to-transfer knowledge to maintain that kind of software. This all benefits the consultants and hurts the companies paying for the software to be built, which only makes sense if Sun was intentionally pushing Java that way.
I wouldn't describe C# as a language that I like, but I think it too has benifited from breaking the mold of C more than Java did (though I attribute most of it's superiority to its designers simply making better decisions in several places). Named and optional arguments stand out in my mind as ways C# did something that had no precedence in C, while Java still has not. (There is that double squiggly bracket trick, but you have to admit that is pretty shoddy).
I do like the way jfb suggests using the concept of 'affordances' with languages/environments, to analyze what sorts of code they encourage. But to really do that, we'd have to actually identify these specific affordances, which i'm not sure how to either.
(And as far as your particular line of argument -- does anything in a processor know what an 'actor' is either? If not, I believe you that you find 'actor' a better abstraction than 'class', but it must not have anything to with either one being something the lower-level computer architectural abstractions 'know about')
There's a saying that one can write COBOL in any language, but nobody is born itching to POST INCREMENT C BY ONE. A given technology has a spirit; that spirit guides the usage of the technology; and people who use that technology, and share a sufficiency of that spirit, will find a welcoming home. That spirit is intrinsic to the technology; changing Java to not rely on Simula style classes for code namespacing would destroy Java -- it'd be something very different, and the usage of this new language would mean entirely new styles of conceptual organization.
I'm not taking a stance in this post on the aesthetics of the various ways to organize programs; but I do think that the forensic exercise of determining the -- I dunno, zeitgeist? -- of a technology is an interesting, rich one.
Unfortunately, Java is also not a very powerful language. Many of those OO gymnastics are only relevant because the language isn't expressive enough to achieve the same results in a simpler, more direct way. Java is the language where design patterns in the Gang of Four sense first became popular, and it's often been suggested that design patterns indicate missing language features.
Exactly right. In previous decades, had they been using modern terminology, calling conventions would no doubt be covered by plenty of "design patterns". We don't speak of calling conventions that way now because languages provide that for us.
For better or worse, Java has much simpler semantics.
PS: THE Java® SE 7 Edition of The Java Language Specification describes all the features that have been added to the Java programming language in Java SE 7. It also integrates changes made to the Java programming language under maintenance since the Third Edition in 2005. http://docs.oracle.com/javase/specs/jls/se7/jls7.pdf. It's 670 pages long.
Unfortunately, among the major industrial programming languages, that is far from the longest specification out there. Moreover, some of the major industrial programming languages don't even have a standard reference specification. Notwithstanding its length, the Java spec is actually fairly efficient and well-organised in comparison.
And if we actually used those languages, we would probably be seeing much lower bug rates in production software already and we could start looking into what else could be improved next. Unfortunately, most of the popular industrial languages don't even get that far. :-(
Paradoxically, this assignment has given me a great deal of respect for the idiots who conceived of the damned thing in the first place.
the perceived elegance of this approach makes junior CS college student eyes glow when s/he first hears about it, and that glow continues for, in the best case, at least a decade after college.
Seems like a bit of a false dichotomy. It is reasonable to expect clear and descriptive names that do not reach the level of verbosity that seems to be idiomatic in Java.
So for a more neutral example, CamelCaseClasses are "idiomatic" in Java, whereas classes_with_underscores are not. You could do either but the first is considered a more "correct" way to write Java, and is what you tend to see in the wild.
As to whether or not the whole persistence mechanism is "over-engineered", well... that's a separate question. I can see some of the arguments for it, but when I look at how much easier my life is with JPQL and Spring Data and the auto-generated JPA classes, versus hand-coding raw JDBC calls and raw SQL, I'll take the former every time. And I, for one, like transactions, and the way Spring lets me annotate my Service Facade classes to manage transactions for me.
The problem is that when you read modern code in other modern languages everything tends to be shorter, still descriptive, and still justifiable. It is something that you can't help but notice if you regularly use multiple languages.
Also, we all have this conversation periodically about the sadness of Spring complexity. They always go the same way - https://news.ycombinator.com/item?id=4550374
I'm curious, how do you propose that part be named? I mean, sure, you can call it part #112176. That's a name with fewer words. The part number is preferable for, say, ordering from a catalog. But when actually designing a device that uses that part? Well, at some point, I need to know what it is. And what it is is a "Phototransistor IR Chip Silicon NPN Transistor 2-Pin T-1".
Sometimes in engineering you just need some really specific thing, and it makes perfect sense for a really specific thing to have a really specific name.
I'm genuinely curious: what is the argument behind your conjecture that nothing should exist that takes so many words to name? Should that phototransistor not exist?
If I look around my office I see lots of things that I could name with that many words, because they're composed of a number of really important properties. The reason they're composed of all of those properties is to serve some purpose, and their name tends to reflect that purpose.
So I guess I'd ask if all of the properties in that part name reflect some holistic idea and suggest a name based on that. But I know I'm probably wrong. The people who make that part may not really know why all those properties are together.. in as much as they have customers that use it for lots of different things. It'll probably end up in things that haven't been invented yet, who knows.
Or maybe we could come up with a holistic name, but because it was unspecific we wouldn't know exactly what it did, and anyone about to purchase that part would have to read the spec-sheet (source code, to briefly exit our analogy).
Let's say we built a device that included that thing. What would we call it when traversing the schematics? We'd probably call it the phototransistor, because everything else is detailed enough to be 'source code'.
You caught me being hyperbolic, though. You're right. Some things deserve complicated names, I still definitely don't think any of those things are classes in Spring though. That shit's cray.
Silicon::Chip::Transistor::NPN::Photo::IR
and then 2-pin and T-1 might be properties on it.
The key word here might be "namespacing". Or it might be something else.
That's the main problem with obscene verbosity in variable naming, at least to me.
Ever heard of kBluetoothAMPManagerCreatePhysicalLinkResponseAMPDisconnectedPhysicalLinkRequestReceived
or
__AVAILABLE_MAC_OS_X_VERSION_10_0_AND_LATER_BUT_DEPRECATED_IN_MAC_OS_X_VERSION_10_5
or
cairo_atsui_font_face_create_for_atsu_font_id_REPLACED_BY_cairo_quartz_font_face_create_for_atsu_font_id
?
com.sun.java.swing.plaf.nimbus.InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonPainter, anyone?
http://javadoc.bugaco.com/com/sun/java/swing/plaf/nimbus/Int...
I don't really see that class as a problem.
One thing I like about DI implemented in a language itself is that is that it negates the need to make factories in all cases. So, essentially, imagine if Java had C# style namespace and this was done using Guice-style DI.
bind(Persistance::Manager.class).toProvider(
new Provider<>() {
public Persistance::Manager get() {
new Persistence::Manager::TransactionAware();
}
});* People trained mostly in camelCase (also, nonprogrammers) read camelCase more accurately, but snake_case faster. (Previous study which I didn't follow up.)
* People trained mostly in snake_case read both of them equally accurately, but snake_case faster. (But, grand total of fifteen participants.)
(I find this mildly surprising: I seem to read snake_case slightly slower than normal text, and camelCase slightly faster, just based on the pauses between words. But camelCase would be easier to lose myself in. I find hyphenated-words easiest to read, but not many languages permit them...)
thisIsAnInstanceOfMyClass
this_is_some_ruby_or_kernel_c_i_copied_from_stack_exchange
_thisIsAFunctionParameterHavingBeenPassedIn
THISISACONSTANTDONOTCHANGE
THIS_IS_A_FRIENDLIER_ENUM
_____how_many_spaces__in_this_var
EDIT: Aaaand then there is the JS approach:
The JDO framework has an interface called PersistenceManagerFactory that is used to... well, create objects that manage persistence. Spring has its own thread-bound PersistenceManager abstraction that you need to fiddle with when you're doing transactions. This class lets you use the former's interface but decorated with the latter's behavior, so code that is designed for JDO doesn't need to be modified to call the Spring APIs explicitly.
(Am I close??)
[0] http://static.springsource.org/spring/docs/2.0.7/api/org/spr...
Quoting part of an article as the title is not necessarily editorialization, and when the link is not actually an article, but a SO question, the original "title" may not be particularly interesting or informative.
Obviously inventing provocative titles simply to spark a flame-war is not on, but in this case the title was humorous (and interesting). The new title which is literally someones question on SO seems out of place on the front page, and not really the point of discussion.
Interesting titles can form part of the culture of a site like this, and over-zealous editing of titles damages the sense of community. It's probably the thing I dislike most about HN right now.
The new title, on the other hand, tells me this is going to be about absurdly long factory classes, almost certainly using Java, and that I should probably be expecting humor rather than, say, a long article about an obscure interaction in Java that produces amusing results (which is what I had hoped I was getting with the original title).
It also happens to be the title of the linked "article" as well, which I believe is what HN says you should be using rather than editorialized titles.
When most of your method/class names overflow your table of contents' width, you've got a serious problem.
My guess is no one bothered to include UX in their annual commitments when they got the memo for the design change.
I mean, it has so much jargon on it, that what I felt is what I think my mom feels when I am talking with my dad...
I read, and re-read, and read again... And the only thing that I would think was: "omgwhy? wtf? WHY THIS EXISTS IN FIRST PLACE???"
like instead of
org.springframework.orm.jdo.TransactionAwarePersistenceManagerFactoryProxy
org.'spring framework'.orm.jdo.'transaction aware persistence manager factory proxy'
$org->{'spring framework'}->orm->jdo->{'transaction aware persistence manager factory proxy'}
use org\{'spring framework'}\orm\jdo\{'transaction aware persistence manager factory proxy'};It makes me wonder if it was just accident that Java developed this way, or if it could have been an xml free, simple interface language.
https://news.ycombinator.com/item?id=5944101
:)
"And this, dear children, is why Java should stop taking drugs."