{"id":188,"date":"2026-04-03T19:19:11","date_gmt":"2026-04-03T22:19:11","guid":{"rendered":"https:\/\/solidchain.ar\/?p=188"},"modified":"2026-04-03T19:19:11","modified_gmt":"2026-04-03T22:19:11","slug":"la-trampa-de-la-abstraccion-cuando-solid-se-convierte-en-over-engineering","status":"publish","type":"post","link":"https:\/\/solidchain.ar\/index.php\/2026\/04\/03\/la-trampa-de-la-abstraccion-cuando-solid-se-convierte-en-over-engineering\/","title":{"rendered":"La Trampa de la Abstracci\u00f3n: Cuando SOLID se convierte en Over-engineering"},"content":{"rendered":"\n

En el mundo del desarrollo de software, los principios SOLID<\/strong> son recibidos como las tablas de la ley. Nos ense\u00f1an que, si los seguimos, nuestro c\u00f3digo ser\u00e1 robusto, escalable y digno de una menci\u00f3n en los anales de la ingenier\u00eda. Sin embargo, hay una verdad inc\u00f3moda que solemos ignorar bajo el entusiasmo de un nuevo proyecto: la abstracci\u00f3n no es gratis.<\/strong><\/p>\n\n\n\n

Como desarrolladores (y especialmente cuando asumimos roles de liderazgo t\u00e9cnico), a veces olvidamos que nuestro objetivo final no es construir una catedral arquitect\u00f3nica, sino entregar valor.<\/p>\n\n\n\n

El “Costo por Capa”<\/h2>\n\n\n\n

Cada interfaz, cada clase abstracta y cada inyecci\u00f3n de dependencia que a\u00f1adimos a un sistema act\u00faa como un impuesto cognitivo<\/strong>.<\/p>\n\n\n\n

    \n
  • Legibilidad:<\/strong> Seguir el flujo de ejecuci\u00f3n se vuelve un ejercicio de arqueolog\u00eda de archivos.<\/li>\n\n\n\n
  • Mantenimiento:<\/strong> Un cambio simple en la l\u00f3gica requiere tocar tres interfaces y cinco implementaciones.<\/li>\n\n\n\n
  • Tiempo:<\/strong> El time-to-market<\/em> se dilata mientras discutimos si una clase cumple estrictamente con el Principio de Responsabilidad \u00danica (SRP).<\/li>\n<\/ul>\n\n\n\n
    \n

    La paradoja de la arquitectura:<\/strong> Muchas veces, por intentar hacer un c\u00f3digo “f\u00e1cil de cambiar en el futuro”, terminamos haciendo que sea “imposible de entender en el presente”.<\/p>\n<\/blockquote>\n\n\n\n

    Los principios bajo la lupa del pragmatismo<\/h2>\n\n\n\n

    Analicemos c\u00f3mo la aplicaci\u00f3n dogm\u00e1tica de SOLID puede jugarnos en contra:<\/p>\n\n\n\n

    1. Responsabilidad \u00danica (SRP) y la fragmentaci\u00f3n infinita<\/h3>\n\n\n\n

    El SRP dice que una clase debe tener una sola raz\u00f3n para cambiar. Llevado al extremo, esto genera un ecosistema de micro-clases de cinco l\u00edneas.<\/p>\n\n\n\n

      \n
    • El problema:<\/strong> La l\u00f3gica de negocio se fragmenta tanto que es imposible entender el “big picture”. El c\u00f3digo se vuelve una sopa de objetos donde la cohesi\u00f3n brilla por su ausencia.<\/li>\n<\/ul>\n\n\n\n

      2. El Principio Abierto\/Cerrado (OCP) y la adivinaci\u00f3n<\/h3>\n\n\n\n

      El OCP nos pide que el c\u00f3digo est\u00e9 abierto a la extensi\u00f3n pero cerrado a la modificaci\u00f3n. Esto suele derivar en el uso excesivo del Patr\u00f3n Strategy<\/strong> o de herencias complejas para escenarios que quiz\u00e1s nunca cambien.<\/p>\n\n\n\n

        \n
      • El problema:<\/strong> Estamos resolviendo problemas que no existen. Si no tienes la certeza de que una l\u00f3gica va a variar en tres formas distintas, un simple if<\/code> o un switch<\/code> es, a menudo, la soluci\u00f3n m\u00e1s elegante y mantenible.<\/li>\n<\/ul>\n\n\n\n

        3. Inversi\u00f3n de Dependencias (DIP): \u00bfInterfaces para todo?<\/h3>\n\n\n\n

        Es com\u00fan ver proyectos en .NET o PHP donde absolutamente cada clase tiene su respectiva interfaz (IUserService<\/code>, IOrderRepository<\/code>).<\/p>\n\n\n\n

          \n
        • El problema:<\/strong> Si solo tienes una implementaci\u00f3n y no planeas cambiarla (por ejemplo, nunca vas a dejar de usar SQL Server por una base de datos de grafos de la noche a la ma\u00f1ana), la interfaz es ruido. Solo a\u00f1ade una capa m\u00e1s de navegaci\u00f3n en el IDE.<\/li>\n<\/ul>\n\n\n\n

          YAGNI: Tu mejor escudo contra el Over-engineering<\/h2>\n\n\n\n

          La regla de oro deber\u00eda ser YAGNI<\/strong> (You Ain’t Gonna Need It<\/em>). Antes de crear una jerarqu\u00eda de clases abstractas para gestionar diferentes tipos de pagos, preg\u00fantate: \u00bfHoy, en este sprint, necesito cobrar con algo que no sea tarjeta de cr\u00e9dito?<\/em><\/p>\n\n\n\n

          Si la respuesta es no, programa para hoy. El buen c\u00f3digo no es el que prev\u00e9 todos los futuros posibles, sino el que es lo suficientemente simple<\/strong> como para ser refactorizado ma\u00f1ana cuando el futuro realmente llegue.<\/p>\n\n\n\n

          La Regla de Tres<\/h3>\n\n\n\n

          Una buena heur\u00edstica es la Rule of Three<\/strong>: No intentes abstraer un patr\u00f3n hasta que no lo hayas visto repetido al menos tres veces en el c\u00f3digo. La primera vez, haz que funcione. La segunda vez, siente un poco de verg\u00fcenza por duplicar. La tercera vez, refactoriza y abstrae<\/strong>.<\/p>\n\n\n\n

          El rol del L\u00edder T\u00e9cnico: Saber cu\u00e1ndo decir “No”<\/h2>\n\n\n\n

          Como l\u00edderes, nuestra responsabilidad es balancear la calidad t\u00e9cnica con la velocidad de entrega. Un equipo senior no es aquel que aplica los patrones m\u00e1s complejos de los libros de dise\u00f1o, sino el que sabe cu\u00e1ndo la simplicidad es la mayor sofisticaci\u00f3n<\/strong>.<\/p>\n\n\n\n

          Escribir c\u00f3digo complejo es f\u00e1cil. Escribir c\u00f3digo simple, que respete lo justo de SOLID para no romperse, pero que sea legible para un junior que entra ma\u00f1ana, es la verdadera maestr\u00eda.<\/p>\n\n\n\n

          C\u00f3digo: Antes y Despu\u00e9s<\/h2>\n\n\n\n

          Para que este concepto no se quede solo en palabras, vamos a verlo con un ejemplo cl\u00e1sico en PHP<\/strong>: enviar un correo de bienvenida a un usuario nuevo.<\/p>\n\n\n\n

          Imagina que estamos en la semana 1<\/strong> de un proyecto (un MVP). Aqu\u00ed es donde solemos pecar de “arquitectos de \u00e9lite”.<\/p>\n\n\n\n

          1. El Enfoque “Over-engineered” (Sobrediagramado)<\/h3>\n\n\n\n

          Siguiendo SOLID al pie de la letra, alguien podr\u00eda construir esto para enviar un simple mail:<\/p>\n\n\n\n

          PHP<\/p>\n\n\n\n

          \/\/ 1. La interfaz (DIP)\ninterface MessageProviderInterface {\n    public function send(string $to, string $subject, string $body): bool;\n}\n\n\/\/ 2. La implementaci\u00f3n concreta\nclass SendGridProvider implements MessageProviderInterface {\n    public function send($to, $subject, $body): bool {\n        \/\/ L\u00f3gica compleja de la API de SendGrid\n        return true;\n    }\n}\n\n\/\/ 3. Un DTO para el mensaje (SRP)\nclass WelcomeMessage {\n    public function __construct(private User $user) {}\n    public function getBody(): string { return \"Hola {$this->user->name}\"; }\n}\n\n\/\/ 4. El servicio que orquestra todo\nclass UserNotificationService {\n    public function __construct(private MessageProviderInterface $provider) {}\n\n    public function notifyWelcome(User $user) {\n        $msg = new WelcomeMessage($user);\n        $this->provider->send($user->email, 'Bienvenido', $msg->getBody());\n    }\n}\n<\/code><\/pre>\n\n\n\n
          El costo:<\/strong> Para enviar un mail, creamos 4 archivos, una interfaz y un sistema de inyecci\u00f3n de dependencias. Si el cliente ma\u00f1ana dice “mejor enviemos el mail desde el controlador directamente porque tenemos prisa”, tenemos que deshacer una catedral.<\/p>\n\n\n\n
          2. El Enfoque Pragm\u00e1tico (YAGNI)<\/h3>\n\n\n\n
          Si solo necesitas enviar un mail y no tienes planes reales de cambiar de proveedor en los pr\u00f3ximos 6 meses, esto es mucho m\u00e1s honesto:<\/p>\n\n\n\n
          PHP<\/p>\n\n\n\n
          class Mailer {\n    public function sendWelcome(User $user) {\n        \/\/ Usamos una librer\u00eda simple o la funci\u00f3n mail()\n        mail($user->email, 'Bienvenido', \"Hola {$user->name}\");\n    }\n}\n\n\/\/ En tu controlador o servicio de registro:\n$this->mailer->sendWelcome($user);\n<\/code><\/pre>\n\n\n\n
          An\u00e1lisis de la “Trampa”<\/h3>\n\n\n\n
          \u00bfPor qu\u00e9 el primer ejemplo es peligroso en etapas tempranas?<\/p>\n\n\n\n
            \n
          1. Indirecci\u00f3n innecesaria:<\/strong> Si quiero saber qu\u00e9 pasa cuando se env\u00eda un mail, en el ejemplo 1 tengo que saltar por 3 archivos. En el ejemplo 2, voy directo al grano.<\/li>\n\n\n\n
          2. Mantenimiento de mocks:<\/strong> Para testear el ejemplo 1, necesito mockear la interfaz, configurar el contenedor de servicios, etc. Para un MVP, a veces un test de integraci\u00f3n simple sobre una clase concreta es 10 veces m\u00e1s r\u00e1pido.<\/li>\n\n\n\n
          3. Falsa flexibilidad:<\/strong> Decimos “uso una interfaz por si cambio SendGrid por Mailchimp”. Realidad:<\/strong> Casi nunca cambias el proveedor principal de infraestructura a mitad de un proyecto, y si lo haces, refactorizar una clase simple (Mailer<\/code>) te llevar\u00e1 20 minutos, lo mismo que te tom\u00f3 escribir toda la arquitectura innecesaria del ejemplo 1.<\/li>\n<\/ol>\n\n\n\n
            Conclusi\u00f3n<\/h2>\n\n\n\n
            No me malinterpretes: SOLID es fundamental.<\/strong> Pero debe ser una br\u00fajula, no una jaula. No permitas que la pureza arquitect\u00f3nica te impida ver el bosque. Al final del d\u00eda, el mejor c\u00f3digo es el que se puede borrar, cambiar y entender sin necesidad de un mapa de tres dimensiones.<\/p>\n\n\n\n
            Menos arquitectura de manual y m\u00e1s sentido com\u00fan.<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"
            En el mundo del desarrollo de software, los principios SOLID son recibidos como las tablas […]<\/p>\n","protected":false},"author":1,"featured_media":191,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"footnotes":""},"categories":[13,1],"tags":[],"class_list":["post-188","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-arquitectura","category-web"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/solidchain.ar\/index.php\/wp-json\/wp\/v2\/posts\/188","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/solidchain.ar\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/solidchain.ar\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/solidchain.ar\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/solidchain.ar\/index.php\/wp-json\/wp\/v2\/comments?post=188"}],"version-history":[{"count":2,"href":"https:\/\/solidchain.ar\/index.php\/wp-json\/wp\/v2\/posts\/188\/revisions"}],"predecessor-version":[{"id":192,"href":"https:\/\/solidchain.ar\/index.php\/wp-json\/wp\/v2\/posts\/188\/revisions\/192"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/solidchain.ar\/index.php\/wp-json\/wp\/v2\/media\/191"}],"wp:attachment":[{"href":"https:\/\/solidchain.ar\/index.php\/wp-json\/wp\/v2\/media?parent=188"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/solidchain.ar\/index.php\/wp-json\/wp\/v2\/categories?post=188"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/solidchain.ar\/index.php\/wp-json\/wp\/v2\/tags?post=188"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}