There you go once again, while performing a code review or after having justified a quick coding in the name of urgency and priority: it clearly stand in front of you yet another helper class. But everything works fine and the show must go on, release after release, so that helper class soon becomes a monster class, providing tons of static methods, freely growing in its utils package, often a no man land of technical debts where the object oriented design didn’t dare to step in. The provided facility is centralized and hence DRY – would shout some developer, may be its coder. It’s fast because everything is static – may claim somebody else within the team, may be the one who added another static method in its list. It’s easy to use, we kept it simple – you could hear in the room, yet another misunderstanding of KISS.
We could argue that often helper and utils classes come to hand really easily, especially when we can’t modify the right target class of the new functionality (located in an external library, for instance) or we actually can’t find that target (unclear domain model, PoC, lack of requirements), or we simply don’t want to find it (laziness, the main global source of helper classes). The big problem though is that’s clearly not an object oriented solution and by the time (and by lack of team communication, resources rotation, quick fixes and workarounds) it could lead to endless containers of static methods and maintenance headaches (you wanted to be DRY, but you end up having ten methods providing almost the same functionality, if not the same; you wanted to be fast, but now you can’t easily add a cache mechanism in that static monster or you get in troubles with concurrency; you wanted to keep things simple, but your IDE now provides a long list of heterogeneous methods which doesn’t simplify your task). But don’t worry, we’ll try to solve it.
Java 8 is there, the promised revolution is finally released, and I am sure that a lot of you are having in mind the same question “Should I use it in my project?”.
Well, I had the same question for few months and today that I have an answer I would like to share it with you. A lot of aspects have been influencing this decision but in this post I want to focus on one in particular that is:
Can I continue to do Continuous Integration with Java 8 and NetBeans Platform?
The main question was around the maturity of the tools necessary to do CI, and how easy was to integrate that with the ant build scripts of the NetBeans Platform.
Fortunately, we found that it is possible and easy to do!
I would also thanks Alberto Requena Sanchez for his contribution on this article.
Conventions are great when you can speed up your coding and automatically provide self-documenting and standard solutions and that’s probably one of the main reasons why the Convention over configuration pattern got so popular and extended. And that’s fine, unless you abuse or misuse them, as usual, breaking user (or reader) expectations and therefore increasing confusion and time consuming (that is, breaking the Principle of least Astonishment, PLA, even in your contracts and interfaces). And often getter and setter methods are part of this overuse of conventions.
The so popular Java Beans convention is really powerful when providing compatibility for frameworks and libraries which rely on the matching between getters/setters and internal properties of a POJO. The side-effects of developers getting used to code Java Beans though is to see getters and setters everywhere! But do we really need so many getters and setters?
Hi, I want to share with you a presentation I did some time ago for explaining what an SOA is to an audience that did not have any knowledge on the subject.
Just make it start, use the arrows to navigate and enjoy! And do not forget to let your feedbacks.
- SOA: Principles of Service Design by Thomas Erl
Marco Di Stefano
Hi all, today I would like to share with you a personal project, that has nothing to do with IT, but a lot in common with refactoring ideas.
Music composition and orchestration, is my great passion, and in the last years I have been putting it apart for more other concrete things. But I never garbaged the idea to continue to compose music, and maybe one day do it at professional level, so finally I decided to bring back to life this passion and here it comes: The First Touch.