With Java EE 7, Design Patterns are dead. Your ear is ugly too

Sometimes it is difficult to tell if Java Champion Adam Good, the author of Java EE Night Hacks and Java EE models, is an iconoclast or a cheerleader. For one thing, he rarely has bad things to say about Java EE and the ever-changing syntax of the language. Yet, on the other hand, he is more than happy to challenge the community on how they have, both now and in the past, approached the task of developing enterprise applications. Bien’s attitude towards various sacred business programming design models is a prime example of this.

From my point of view, we should focus on business logic and forget about technology.

Adam Bien, Java champion

Iconoclastic, Bien claims that most of the established J2EE and Gang of Four (GoF) models are no longer relevant to today’s enterprise developers. He advocates a style of continuous development that rejects superfluous and obsolete blueprints. best practices. It’s skinny, it’s mean, and it’s definitely opinionated.

“There are no templates for Java EE6 or Java EE7. From my perspective, we should focus on business logic and forget about technology. In my JavaOne session, I created an application from zero, in an hour, demonstrating some of the best practices. I call it opinionated because it is an opinion. There might be other best practices out there, but here’s my thoughts on what an app should look like. Very simple and very easy to build. “

Here are a few other ideas and opinions that Bien has shared with us over the past year that tend to anger other advocates of the corporate Java programming community:

  1. Low productivity is not a problem with the Java language, it is a problem with architects who read a book of models and apply it to their project, whether it makes sense or not. This is why they end up with 2% business logic and 98% bloat.
  2. Switching to another language like Scala or Groovy is generally not necessary for businesses. You should just approach Java in a smarter way.
  3. Your system should not depend on your IDE. Each developer must be able to choose the development environment they want. All the support you really need is coffee.
  4. If you need a special assortment and wide-range IDE plugins to be productive, that’s a bad sign. Start NetBeans, launch the Maven Build Automation Tool, and get down to coding!
  5. If you don’t need it, get rid of it. It can apply to XML, additional plugins, whatever. Start lean, with a little POM. This is the number one way to ensure that the subsequent developers of the project understand what is going on behind the scenes. There shouldn’t be Magic Where Black Box development.
  6. Don’t be so anxious to break up and distribute the code; WARs can be better than EARs when it comes to packaging; monolithic is not always bad. Organizations don’t need 500 modules because they won’t be able to handle all interfaces and interactions. Keep your code and projects together until they get too big; then create a second monolith and let the two giants communicate via REST.

Of course, Adam doesn’t just churn out opinionated Java without backing it up. At JavaOne, he not only defended his particular approach to development, but he also step by the development of a simple application who embraced his design ideals, all in less than an hour. He may not be an iconoclast. And it might not be fair to call her a cheerleader. Maybe we’ll be content with what he calls himself: opinionated.

Learn more about Java ALM

Source link

Abdul J. Gaspar

Leave a Reply

Your email address will not be published.