EJB 3.1: No necesitas interfaces si total no vas a hacer tests

El viernes pasado TheServerSide publicaba un artículo sobre EJB 3.1 que habla de dos de las novedades de EJB 3.1: las interfaces opcionales y los singleton.

Atención a lo que su autor escribe en un momento dado respecto a las interfaces opcionales:

Interface-based programming is clearly a useful technique in writing loosely-coupled, unit-testable applications. That is precisely why both EJB 2.1 and Spring promote the idea of component interfaces. In fact, at least one interface is required even for EJB 3.0 Session Beans (this is not a requirement for EJB 3.0 Message Driven Beans).

Bien, hasta ahora todo bien. Ojo al siguiente párrafo que no tiene desperdicio:

The trouble is that component interfaces are just a needless abstraction in a lot of circumstances. I can't remember the times I silently cursed under my breath as I carried out the mechanical task of writing interfaces just because the framework needed it or the architect sitting in some ivory tower mandated it. A lot of times, just a regular Java object is really all you need for your foreseeable needs, especially if you don't really do much unit testing and loose-coupling is just not enough of a concern for the application.

Me pierdo un poco en este párrafo. Corregidme si me equivoco, pero me parece entender que ahora ya no necesitamos las interfaces porque hay ocasiones en que, total, no vamos a hacer tests unitarios, y que no nos preocupa el acoplamiento entre los componentes.

Yo creo que a veces todo esto de los hands-on architects, pragmatic architects, etc. se le va a la gente tan de las manos, que hasta se utiliza para justificar lo injustificable. Señores autores de la especificación de EJBs (sé que no me leen, no sé para que me dirijo a ellos), el desarrollo basado en interfaces es fundamental dentro de la programación de componentes ya que la testabilidad y el desacoplamiento son características fundamentales en estos sistemas. Y les pese o no, un EJB es exactamente eso, un componente. Es lo que ha sido siempre, y tampoco hay ido tan mal (al menos desde EJB 2.x).

Una cosa está clara, y ha sido así toda la vida. El que mucho abarca, poco aprieta. Y está claro que estos señores quieren abarcar mucho. Demasiado. Incluso a expensas de sugerir cosas como no hacer tests unitarios. En fin, cuando lees estas perlas de un miembro de la spec. de EJB 3 y JEE 6, y autor de EJB3 in Action, te das cuenta del despropósito total y el sin sentido que ha sido esta tecnología durante todo este tiempo.

Más les valdría haber estandarizado Spring y mantener EJB 2.x que tampoco era tan malo.