translations - Patrón de fábrica en Python

mastering bitcoin pdf español gratis (3)

Actualmente estoy implementando el patrón de diseño de Fábrica en Python y tengo algunas preguntas.

¿Hay alguna manera de evitar la instanciación directa de las clases concretas reales? Por ejemplo, si tengo una VehicleFactory que genera vehículos, quiero que los usuarios simplemente usen esa fábrica y eviten que alguien accidentalmente cree una instancia de Car () o Truck () directamente. Puedo lanzar una excepción en init () quizás, pero eso también significaría que la fábrica no puede crear una instancia de la misma ...
Ahora me parece que las fábricas se vuelven adictivas. Parece que todo debería convertirse en una fábrica para que cuando cambie la implementación interna, los códigos del cliente no cambien. Me interesa saber cuándo hay una necesidad real de usar fábricas y cuándo no es apropiado usarlas. Por ejemplo, podría tener una clase Window y ahora solo hay una de este tipo (sin PlasticWindow, ReinforcedWindow o algo así). En ese caso, ¿debería usar una fábrica para que el cliente genere la ventana, en caso de que agregue más tipos de Windows en el futuro?
Me pregunto si hay una forma habitual de llamar a las fábricas. Por ejemplo, ahora estoy llamando a mi fábrica de vehículos como vehículos, por lo que los códigos serán algo así como Vehículos.crear (...). Veo muchos tutoriales haciéndolo como VehicleFactory, pero me parece demasiado largo y de alguna manera expone la implementación.

EDITAR: Lo que quise decir con "expone la implementación" es que le permite a las personas saber que es una fábrica. Lo que sentí fue que el cliente no necesita saber que es una fábrica, sino más bien una clase que puede devolver objetos para usted (que es una fábrica, por supuesto, pero tal vez no haya necesidad de decir esto explícitamente a los clientes). Sé que los códigos soure se exponen fácilmente, así que no quise decir "exponer cómo se implementan las funcionalidades en los códigos fuente".

¡Gracias!

¿Hay alguna manera de evitar la instanciación directa de las clases concretas reales?

¿Por qué? ¿Son tus programadores malos sociópatas que se niegan a seguir las reglas? Si proporciona una fábrica, y la fábrica hace lo que la gente necesita, entonces usarán la fábrica.

No puedes "evitar" nada. Recuerda. Esto es Python: tienen la fuente.

¿Debo usar una fábrica para que el cliente genere la ventana, en caso de que agregue más tipos de Windows en el futuro?

Meh. Ni bueno ni malo. Puede ser engorroso administrar todos los detalles de la jerarquía de clases y la fábrica.

Agregar una fábrica no es difícil. Este es Python, tienes toda la fuente en todo momento, puedes usar grep para encontrar un constructor de clase y reemplazarlo con una fábrica cuando lo necesites.

Ya que puedes usar grep para encontrar y corregir tus errores, no necesitas planear este tipo de cosas tanto como lo harías en Java o C ++.

Veo muchos tutoriales haciéndolo como VehicleFactory, pero me parece demasiado largo y de alguna manera expone la implementación.

"Demasiado largo"? Se usa tan raramente que apenas importa. Use nombres largos: ayuda a otras personas a entender lo que está haciendo. Esto no es Code Golf donde menos golpes de teclado gana.

"expone la implementación"? Primero, no expone nada. En segundo lugar, este es Python, tienes toda la fuente en todo momento, todo está ya expuesto.

Deja de pensar tanto en prevención y privacidad. No es útil.

No exponga la clase (por ejemplo, __MyClass privado __MyClass , u obvio que no quiere que se use directamente _MyClass ). De esta forma, solo se puede crear una instancia a través de la función de fábrica.
Tal vez debería revisar el uso de los argumentos de las palabras clave y la herencia. Parece que no los tiene en cuenta, lo que generalmente reducirá su dependencia de fábricas complejas (para ser sincero, rara vez he necesitado fábricas).
En Python no puede protegerse fácilmente contra la exposición de la implementación, va en contra del Zen de Python . (Es lo mismo en cualquier idioma, un individuo determinado puede obtener lo que quiera con el tiempo). A lo sumo, debe intentar asegurarse de que un usuario de su código no haga lo incorrecto accidentalmente , pero nunca presuma de saber qué puede decidir el usuario final con su código. No lo ofusque y dificulte trabajar con él.

Sé Ptónico. No complique demasiado su código con soluciones de lenguaje "empresarial" (como Java) que agreguen niveles innecesarios de abstracción.

Tu código debe ser simple e intuitivo. No debería necesitar delegar en otra clase para instanciar otra.