Buenassss.... bueno, primero gracias por haberme nombrado dos veces, mi ego está en sus más altos niveles
Quiero usar una frase de un colega:
"esta solución es para 'este' contexto, si me cambian el contexto, la solución será otra".
También puedo inventar una (basada en "Groucho Marx"):
"Estas son mis opiniones. Si a usted no le gustan, tengo otras".
Dejando las bromas de lado, a lo que voy, fuera de que lo que yo diga o escriba no es ley (y creo que tampoco deberías tomar a nadie así), habría que sacar nuestras propias conclusiones de acuerdo a nuestro nuestra experiencia, nuestro sentido común y nuestro contexto.
La opinión de Casuis la respeto, pero puedo discrepar con ella (lo que no quiere decir que uno u otro esté realmente equivocado, todo dependerá del contexto). El mejor ejemplo que tengo de
"abstracción sobre abstracción" son todas las capas que pueden tener arquitecturas de tipo J2EE (java).
El tema es, en mi opinión, discernir si estamos construyendo un cañón láser para matar moscas o una revista enrollada para matar mamuts.
En los desarrollos que he participado, en un principio usamos herramientas similares a Zend, que nos resolvía la
"capa de abstracción" que nos evita trabajar directamente con una base de datos, facilitando a su vez si deseábamos migrar de motor.
También me sucedió que estando "casados" con una herramienta que tenía la responsabilidad de resolver la problemática de esa "capa", decidimos cambiar de herramienta por otra que nos ofrecía distintas prestaciones.
Finalmente, creamos una capa de abstracción nueva, que nos permitía subir un nivel más para evitar este tipo de situaciones (que perfectamente podemos estar hablando de una simple implementación del patrón "Fachada").
Pero la pregunta es siempre la misma: ¿en tu "caso" (contexto) es rentable aplicar una estrategia similar?
Si es poco probable que te suceda, o solo te va a pasar una vez, tal vez no tenga sentido hacer esto, de forma tan concreta.
Pero creo que sí deberíamos tener en cuenta algunas guías "generales" de diseño:
- "No dependas de implementaciones concretas, en lo posible, de implementaciones abstractas".
- Encuentra el posible "foco de cambio", y busca la forma de "contenerlo" (alguna estrategia, por ejemplo, un patrón de diseño, etc).
PD: por regla, si no te gustan las respuestas que puedan dar a tus preguntas, no hagas preguntas, y haz lo que te parezca mejor. Aprender es equivocarse