Descubrí que puedo pasar 8 argumentos a un constructor de clase o simplemente pasar la variable de formulario.¿Es malo el diseño de pasar un formulario como argumento a una clase solo para acceder a algunas de sus variables o métodos?
Sin embargo, dado que no estoy usando todo en el formulario, parece que puede ser un mal diseño.
Además, los objetos a los que sí accedo necesitarían proporcionar accesos.
¿Viola los principios de OOP?
Depende: si está utilizando el formulario como ese tipo específico de formulario, y "lógicamente" tiene sentido que esté trabajando con el formulario, entonces, por supuesto, pase una referencia al formulario.
Es igual que cualquier otra clase - Si yo iba a ser el acceso a los elementos de un "empleado", me gustaría escribir:
void DoSomething(Employee employee) { ...
En lugar de:
void DoSomething(string firstName, string lastName, DateTime hireDate...) { ...
La primera es muy limpio y obvio.
Sin embargo, si los datos que está utilizando no están relacionados con el formulario, sería mejor encapsularlo en su propia clase utilizable tanto por la forma como por su clase.
Además, los objetos a los que accedo necesitarían proporcionar accesos.
Si este es el caso, sospecho que tener una clase encapsulando los datos es probablemente un mejor diseño ... El formulario podría exponer una propiedad o método que devuelve una instancia de esa clase, y pasarlo a su segunda clase.
¿Cuántos formularios tiene que contienen datos que no están relacionados con el formulario? Estoy un poco preocupado de que alguien lea esto y lo tome como una licencia para pasar AddCustomerForm a su SaveCustomerMethod. ¿Lo tolerarías? –
@Justin: No, yo personalmente guardo mis formularios completamente separados de los datos específicos del dominio ... Estoy de acuerdo con sus inquietudes. –
Al pasar una forma de interfaz gráfica de usuario a otros componentes de la interfaz gráfica de usuario o, lo que es peor, un modelo/biblioteca que sí funciona rompe la encapsulación y crea un acoplamiento ajustado.
El formulario debe abstraer los datos y el modelo a continuación. Otras clases de modelos o bibliotecas deberían pasar objetos modelo. Un patrón típico es "enlazar" la capa gui al modelo.
En lugar de pasar 8 variables, ¿las 8 variables se dividen lógicamente en objetos diferentes? Idealmente, pasaría un objeto o conjunto de objetos que pueden contener colectivamente 8 variables miembro. Luego, simplemente puede pasar referencias a objetos que están contenidos en el mismo modelo que su GUI está abstrayendo y enlazando.
Sin ver la clase, casi puedo garantizar que la clase que toma 8 argumentos está violando el Principio de Responsabilidad Individual. Podría ser una clase generada para representar una tabla en una base de datos (o algo por el estilo) en cuyo caso debería encapsularla en su propia clase para pasarla en lugar de la forma.
Otra cosa a tener en cuenta es que el formulario que está revisando también infringe SRP, ya que muestra los datos y que se utilizan como respaldo de otro formulario.
Se normalmente es porque normalmente personas son perezosos o no entienden cómo utilizar los eventos, por lo que escribir código como este:
class MainForm : Form
{
// stuff
}
class ChildForm : Form
{
private MainForm _mainFrm;
public ChildForm(MainForm frm)
{
_mainFrm = frm;
}
private void someButton_Click(...)
{
_mainFrm.UpdateSomeText();
}
}
Ese código crea un acoplamiento entre dos terribles diferente Clases de UI. Ahora, en un proyecto simple, interno, quizás desechable, probablemente esté bien y puedes escribirlo una vez y seguir adelante. En general, significa que muy bien puede necesitar cambiar su clase ChildForm en respuesta a cambios en su clase MainForm, lo cual es indeseable y se puede evitar a través de mecanismos de acoplamiento débiles como eventos.
Por otro lado, hay casos válidos para pasar en un formulario a un método o constructor, aunque estas situaciones son menos comunes en la práctica. Todo se reduce a lo que está haciendo el código y si está diseñado de manera óptima. No hay un libro de reglas para esto, lleva años de práctica y requiere que usted cometa muchos errores primero para que sepa qué evitar antes de escribir cualquier código.
Puedo imaginarme una clase que controla el formateo de un formulario (fuente, tamaño, color, etc.) que podría tomar una variable del tipo Formulario como argumento. Podría argumentar que esa estructura no violaría los principios OO. Cualquier cosa menos que probablemente no.
Incluso si necesita detalles del cliente en la nueva clase y tiene la tentación de pasar el formulario del cliente, que contiene todos los detalles que necesita, NO LO HAGA. Cree una clase de cliente, proporcione una instancia de esa clase del formulario y pase esa instancia a la nueva clase. Si alguna vez cambia la interfaz de usuario, o si alguna vez necesita automatizar parte del flujo de trabajo que solía ser manual, se alegrará de haberlo hecho.
"Acércate a un lado de la carretera y déjame ver tu licencia OOP" - No creo que exista un Código de Hammurabi para OOP tan universalmente aceptado. Amigo, si funciona, úsalo. Si no es así, cámbialo. – duffymo
Necesitamos más contexto. En general, no me gusta ver un formulario pasado, pero supongo que podría depender de lo que estás haciendo. – wllmsaccnt
@duffymo, esa filosofía era una mala idea en los años 60 y lo mismo se aplica a OOP. Él no está preguntando si funciona o no ... claramente está buscando consejos y un ** diseño ** bueno, ¡no cómo hackear el código de spaghetti! – Josh