retranslated by GPT-4 (only EN version)

Author: dg

dependency-injection/bg/introduction.texy

@@ -100,7 +100,7 @@ Si sigues esta regla siempre y en todas partes, estarás en camino hacia un cód
 Esta técnica se denomina de forma experta **inyección de dependencias**. Y los datos se llaman **dependencias.** Pero es un simple paso de parámetros, nada más.
 
 .[note]
-Por favor, no confundas la inyección de dependencias, que es un patrón de diseño, con el "contenedor de inyección de dependencias", que es una herramienta, algo completamente diferente. Hablaremos de contenedores más adelante.
+Por favor, no confundas la inyección de dependencias, que es un patrón de diseño, con un "contenedor de inyección de dependencias", que es una herramienta, algo diametralmente distinto. Nos ocuparemos de los contenedores más adelante.
 
 
 De las funciones a las clases .[#toc-from-functions-to-classes]
@@ -245,7 +245,7 @@ class Article
 ```
 
 .[note]
-Si eres un programador experimentado, podrías estar pensando que `Article` no debería tener un método `save()` en absoluto, debería ser un componente de datos puro, y un repositorio separado debería encargarse del almacenamiento. Esto tiene sentido. Pero eso nos llevaría mucho más allá del tema, que es la inyección de dependencias, e intentar dar ejemplos sencillos.
+Si usted es un programador experimentado, podría pensar que `Article` no debería tener un método `save()` en absoluto; debería representar un componente puramente de datos, y un repositorio separado debería encargarse de guardar. Eso tiene sentido. Pero eso nos llevaría mucho más allá del alcance del tema, que es la inyección de dependencias, y del esfuerzo por proporcionar ejemplos sencillos.
 
 Si vas a escribir una clase que requiere una base de datos para funcionar, por ejemplo, no te imagines de dónde obtenerla, sino que te la pasen. Quizá como parámetro de un constructor u otro método. Declara las dependencias. Exponlas en la API de tu clase. Conseguirás un código comprensible y predecible.
 
@@ -306,9 +306,9 @@ $logger->log('The temperature is 15 °C');
 Pero no me importa! .[#toc-but-i-don-t-care]
 --------------------------------------------
 
-*"Cuando creo un objeto Article y llamo a save(), no quiero tratar con la base de datos, sólo quiero que se guarde en la que he establecido en la configuración. "*
+*"Cuando creo un objeto Article y llamo a save(), no quiero tratar con la base de datos, sólo quiero que se guarde en la que he establecido en la configuración."*
 
-*"Cuando uso Logger, sólo quiero que se escriba el mensaje, y no quiero ocuparme de dónde. Que se use la configuración global. "*
+*"Cuando uso Logger, sólo quiero que se escriba el mensaje, y no quiero ocuparme de dónde. Que se use la configuración global."*
 
 Estos comentarios son correctos.
 
@@ -379,21 +379,21 @@ Ahora está claro por las firmas de la clase `NewsletterDistributor` que el regi
 Además, si se cambia el constructor de la clase `Logger`, no tendrá ningún efecto en nuestra clase.
 
 
-Regla nº 2: Toma lo que es tuyo .[#toc-rule-2-take-what-is-yours]
------------------------------------------------------------------
+Regla nº 2: Toma lo que es tuyo .[#toc-rule-2-take-what-s-yours]
+----------------------------------------------------------------
 
-No te dejes engañar y no dejes que te pasen los parámetros de tus dependencias. Pasa las dependencias directamente.
+No te dejes engañar y no te dejes pasar las dependencias de tus dependencias. Sólo pasa tus propias dependencias.
 
 Esto hará que el código que utilice otros objetos sea completamente independiente de los cambios en sus constructores. Su API será más verdadera. Y lo más importante, será trivial cambiar esas dependencias por otras.
 
 
-Un nuevo miembro de la familia .[#toc-a-new-member-of-the-family]
------------------------------------------------------------------
+Nuevo miembro de la familia .[#toc-new-family-member]
+-----------------------------------------------------
 
-El equipo de desarrollo decidió crear un segundo registrador que escribe en la base de datos. Así que creamos una clase `DatabaseLogger`. Así que tenemos dos clases, `Logger` y `DatabaseLogger`, una escribe en un archivo, la otra escribe en una base de datos ... ¿no crees que hay algo extraño en ese nombre?
-¿No sería mejor renombrar `Logger` a `FileLogger`? Claro que sí.
+El equipo de desarrollo decidió crear un segundo registrador que escribe en la base de datos. Así que creamos una clase `DatabaseLogger`. Así que tenemos dos clases, `Logger` y `DatabaseLogger`, una escribe en un archivo, la otra en una base de datos ... ¿no te parece extraña la nomenclatura?
+¿No sería mejor renombrar `Logger` a `FileLogger`? Desde luego que sí.
 
-Pero hagámoslo de forma inteligente. Crearemos una interfaz con el nombre original:
+Pero hagámoslo de forma inteligente. Creamos una interfaz con el nombre original:
 
 ```php
 interface Logger
@@ -402,7 +402,7 @@ interface Logger
 }
 ```
 
-...que ambos registradores implementarán:
+... que ambos registradores implementarán:
 
 ```php
 class FileLogger implements Logger
@@ -412,17 +412,17 @@ class DatabaseLogger implements Logger
 // ...
 ```
 
-Y de esta forma, no será necesario cambiar nada en el resto del código donde se utilice el logger. Por ejemplo, el constructor de la clase `NewsletterDistributor` seguirá contentándose con requerir `Logger` como parámetro. Y dependerá de nosotros qué instancia le pasemos.
+Y debido a esto, no habrá necesidad de cambiar nada en el resto del código donde se utilice el logger. Por ejemplo, el constructor de la clase `NewsletterDistributor` seguirá conformándose con requerir `Logger` como parámetro. Y dependerá de nosotros qué instancia le pasemos.
 
-**Esta es la razón por la que nunca damos a los nombres de interfaz el sufijo `Interface` o el prefijo `I`.** De lo contrario, sería imposible desarrollar código de esta forma tan agradable.
+**Por eso nunca añadimos el sufijo `Interface` o el prefijo `I` a los nombres de las interfaces.** De lo contrario, no sería posible desarrollar el código de forma tan agradable.
 
 
 Houston, tenemos un problema .[#toc-houston-we-have-a-problem]
 --------------------------------------------------------------
 
-Mientras que en toda la aplicación podemos estar contentos con una única instancia de un logger, ya sea de fichero o de base de datos, y simplemente pasarlo allí donde se registre algo, es bastante diferente en el caso de la clase `Article`. De hecho, creamos instancias de ella según sea necesario, posiblemente varias veces. ¿Cómo tratar el enlace a la base de datos en su constructor?
+Mientras que podemos arreglárnoslas con una única instancia del registrador, ya sea basado en archivos o en bases de datos, a lo largo de toda la aplicación y simplemente pasarlo allí donde se registre algo, es bastante diferente para la clase `Article`. Creamos sus instancias según sea necesario, incluso varias veces. ¿Cómo tratar la dependencia de la base de datos en su constructor?
 
-Como ejemplo, podemos utilizar un controlador que debe guardar un artículo en la base de datos después de enviar un formulario:
+Un ejemplo puede ser un controlador que debe guardar un artículo en la base de datos después de enviar un formulario:
 
 ```php
 class EditController extends Controller
@@ -437,17 +437,17 @@ class EditController extends Controller
 }
 ```
 
-Se ofrece directamente una posible solución: hacer que el objeto de base de datos sea pasado por el constructor a `EditController` y utilizar `$article = new Article($this->db)`.
+Una posible solución es obvia: pasar el objeto de base de datos al constructor `EditController` y utilizar `$article = new Article($this->db)`.
 
-Como en el caso anterior con `Logger` y la ruta del archivo, este no es el enfoque correcto. La base de datos no es una dependencia de `EditController`, sino de `Article`. Así que pasar la base de datos va en contra de [la regla nº 2: toma lo que es tuyo |#rule #2: take what is yours]. Cuando se cambia el constructor de la clase `Article` (se añade un nuevo parámetro), también habrá que modificar el código en todos los lugares donde se crean instancias. Ufff.
+Al igual que en el caso anterior con `Logger` y la ruta del archivo, este no es el enfoque correcto. La base de datos no es una dependencia de `EditController`, sino de `Article`. Pasar la base de datos va en contra de [la regla #2: toma lo que es tuyo |#rule #2: take what's yours]. Si el constructor de la clase `Article` cambia (se añade un nuevo parámetro), tendrás que modificar el código allí donde se creen instancias. Ufff.
 
 Houston, ¿qué sugieres?
 
 
 Regla nº 3: Deje que se encargue la fábrica .[#toc-rule-3-let-the-factory-handle-it]
 ------------------------------------------------------------------------------------
 
-Al eliminar los enlaces ocultos y pasar todas las dependencias como argumentos, obtenemos clases más configurables y flexibles. Y por lo tanto necesitamos algo más para crear y configurar esas clases más flexibles. Lo llamaremos fábricas.
+Al eliminar las dependencias ocultas y pasar todas las dependencias como argumentos, hemos conseguido clases más configurables y flexibles. Y por lo tanto, necesitamos algo más para crear y configurar esas clases más flexibles para nosotros. Lo llamaremos fábricas.
 
 La regla general es: si una clase tiene dependencias, deja la creación de sus instancias a la fábrica.
 
@@ -518,10 +518,10 @@ Resumen .[#toc-summary]
 
 Al principio de este capítulo, prometimos mostrarte una forma de diseñar código limpio. Basta con dar a las clases
 
-- [las dependencias que necesitan |#Rule #1: Let It Be Passed to You]
-- [y no lo que no necesitan directamente |#Rule #2: Take What Is Yours]
-- [y que los objetos con dependencias se hacen mejor en fábricas |#Rule #3: Let the Factory Handle it]
+- [pasen las dependencias que necesitan|#Rule #1: Let It Be Passed to You]
+- [a la inversa, no pasen lo que no necesitan directamente |#Rule #2: Take What's Yours]
+- [y que los objetos con dependencias se creen mejor en fábricas |#Rule #3: Let the Factory Handle it]
 
-Puede no parecerlo a primera vista, pero estas tres reglas tienen implicaciones de gran alcance. Conducen a una visión radicalmente distinta del diseño de código. ¿Merece la pena? Los programadores que han desechado viejos hábitos y han empezado a utilizar sistemáticamente la inyección de dependencias lo consideran un momento crucial en su vida profesional. Les ha abierto un mundo de aplicaciones claras y sostenibles.
+A primera vista, puede que estas tres reglas no parezcan tener consecuencias de gran alcance, pero conducen a una perspectiva radicalmente distinta del diseño de código. ¿Merece la pena? Los desarrolladores que han abandonado viejos hábitos y han empezado a utilizar sistemáticamente la inyección de dependencias consideran este paso un momento crucial en su vida profesional. Les ha abierto el mundo de las aplicaciones claras y mantenibles.
 
-Pero, ¿qué ocurre si el código no utiliza sistemáticamente la inyección de dependencias? ¿Y si se basa en métodos estáticos o singletons? ¿Supone algún problema? [Lo hace, y es muy |global-state] significativo.
+Pero, ¿qué ocurre si el código no utiliza sistemáticamente la inyección de dependencias? ¿Y si se basa en métodos estáticos o singletons? ¿Causa problemas? [Sí, los hay, y muy fundamentales |global-state].