lolloj - Fotolia
For the past few years, Tuesdays at JavaOne for TheServerSide team have been dedicated to shooting videos in the press room. These short, five- or 10-minute interviews with rising stars and stalwarts of the Java community not only make for great site content, but the process also provides an opportunity to catch up with longstanding friends, including experts who have contributed articles, or have been available for podcasts or story quotes, and developers who have just generally been good community members. Some of the usual suspects include Daniel Bryant, Reza Rahman, Rob Terpilowski and Barry Burd.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Another longstanding friend, dating way back to the time he presented at the final TheServerSide Java Symposium event, is freelancer Adam Bien. This Tuesday, Bien couldn't make it to the pressroom, as his Tuesday was consumed not only by his JavaOne talk about Java EE and containers, but also by the fact that there were a bunch of sessions he was eager to attend. "At other conferences, I just hang around. But at JavaOne, I attend sessions," Bien said. "I come to JavaOne to learn stuff."
YAGNI: You ain't gonna need it
And though Bien couldn't make it to the pressroom, we did manage to track him down after his microservices session and shoot a five-minute interview. The interview was largely a summary on Bien's take on why Java EE is a great fit for microservices development, along with his insights on how the enterprise environment we all know and love is more than enough to fulfill that vast majority of a software project's needs.
Unfortunately, the most interesting part of our conversation happened after the videographer stopped recording, as Bien and I talked for a bit about the software development experiences we have had, sharing some of the common frustrations with antipatterns we have when maintaining other people's code.
"You can really reduce the amount of code people write," Bien said. When asked how, without referencing it explicitly, Bien basically channeled the old YAGNI mantra. You Ain't Gonna Need It is a well-respected, antipattern-fighting phrase in the world of software development. But its chanting is typically more lip service than an actual call to action, as architects will proselytize clean code in planning meetings, but then design services replete with objects injected into places where a constructor would suffice, interfaces implemented when there is no reasonable prospect future pluggability and class hierarchies abstracted out to such an extreme that even Pablo Picasso would be critical of it.
YAGNTI: You ain't gonna need that interface
One of my pet peeves has always been the impl class antipattern. I blame the popularity of Spring and dependency injection (DI) for the rise of this antipattern. The antipattern goes like this: A developer needs a class, such as a LibraryController, but they want to use DI. So, instead of creating a LibraryController class, they create a LibraryController interface. Then, they create a class called LibraryControllerImpl, which implements the interface. Of course, the whole point of an interface is to provide a pluggability point, where multiple implementations can be used. But the practice of actually creating an impl class directly contradicts the idea of pluggability. If there is only ever going to be one implementation of that component, what's the point of having an interface? What's the point of having a pluggability point if you're never going to plug anything into it?
But what I found particularly amusing was how Bien backed up his argument. "When I go in and help teams, I have access to their SVN. I can go back seven years and see that the interface has never changed, or the XML has never changed. In seven years, they have never plugged anything different in. That's proof that the interface was never needed," Bien said.
The fact is, it's easy to write good, clean code in Java EE. It actually takes more time and effort to sprinkle superfluous interfaces, XML, configuration code and safe injection sites all over your application. Keep your code clean and simple, and the rest of the software development team will love you for it.
Moving to Java EE now
Docker the talk at JavaOne 2016
Digital transformation at JavaOne
Dig Deeper on REST Web services
Cameron McKenzie asks:
Which antipatterns do you see most commonly in recently developed software?
0 ResponsesJoin the Discussion