Java is simple: you bureaucratizes that their projects
Always bothered me quite the whole story that Java is a verbose language and made this are complex systems. So I decided to write this post to show some mistakes made by developers that really make no verbose language, but their true designs machines “burrocráticas”.
This is a first post about some mistakes that encounter: can arise others in the near future.
For what interfaces?
This is a point that is very clear when you schedule some time on platforms like Grails, Ruby on Rails or Node.js and then takes a revitalization project of bequests made in Java. We read in many books or lectures the following principle:
“Program to an interface, not an implementation”
The principle is exactly right, but the fundamental question that motivates is not made: for what need an interface? Answer: to represent an abstraction, that is, what is essential in the service and shared by all its different implementations.
So if there is only an implementation of a class in the system that you need to create an interface ? There is nothing abstract there.
Tip one: create interfaces only if there is more than one implementation of the service whose functionality you want abstracting .
DAOs unnecessary when using an ORM
It is another mistake I encounter often : Imagine that your system has twelve domain classes , they all persisted against the same database ( relational or not). A common pattern that I see is the abusive generation of objects and classes in the system:
An interface to represent the DAO for each entity .
The implementation for that interface DAO
All the DAOs are performed against the same database
DAO exposes some queries , but these in their overwhelming majority ( if not all ) are used by a single system class ..
Taking into account that the role of DAO is accessing and writing data in a data repository , and there is a tool called ORM , find interesting always raise a few questions:
Within the near future you see yourself changing your DBMS for some technology or completely different supplier?
Your design needs to handle different types of persistence according to the environment in which it is deployed?
If you use an ORM ( such as Hibernate , EclipseLink or JPA ) for all domain classes , and all are persisted against the same data repository , really need to be implemented N DAOs only to persist the state of these ?
If there is only one implementation of DAO , really need an interface ?
Queries exposed for their DAO are used by more than one component of the system ?
My suggestion here is simple: ORMs already provide in a generic DAO by default (think Entity Manager JPA): take advantage of it. That’s exactly what Grails does and I see almost a decade ago, it works great! We do not write DAOs in Grails: our services use only the queries that really need and when there is a shared query, the system to expose the rest through a function.
If you have a service responsible for managing the business logic that involves one or more domain classes, and also possess an ORM already dealing well with the persistence process, for what be creating DAOs that expose queries used by a single point system for all the rest?
Simple solution: write your service with a set of well-defined public methods that expose the same customers just what should be seen (this is called encapsulation). If it needs to interact with the database, use this generic DAO provided by ORM internally in their service and avoid with this create a series of components that will only increase the amount of code you need to manage in the future.
In this post I explained only two situations that I see repeatedly in Java projects that can easily be avoided. I completely understand what motivates the occurrence of these errors : you want to do well but not reflected on the good practice that most likely you have been imposed and not displayed.
_ Ah … but what if in the future my system need …
_ Good : if you know what will happen , you do not have a “what if ” , but a “go” , then apply .
_ But the future is unpredictable, I need to prepare for it.
_ Nifty : that then you have a less complex code base to be able to adapt quickly to it.