c# - Implementar una propiedad o implementar una subclase.
java oop (5)
Tengo una clase llamada List_Field que, como su nombre indica, crea campos de entrada de lista. Estos campos de entrada de lista permiten a los usuarios seleccionar un solo elemento por lista.
Quiero poder crear campos de entrada de lista que permitan a los usuarios seleccionar varios elementos por lista, por lo que tengo el siguiente dilema:
¿Debo hacerlo mediante la implementación de una propiedad multiple_choice_allowed en la propiedad List_Field existente, o debo implementar una subclase Multiple_Choice_List_Field de la clase List_Field ?
¿Cuál es el principio de ingeniería que debo seguir cuando me enfrente a dilemas como este?
Debería hacerlo a través de la implementación de una propiedad multiple_choice_allowed en la propiedad List_Field existente
Si puedes hacer eso, creo que es la mejor solución porque así evitas la proliferación de clases. Si al hacerlo está complicando demasiado su clase List_Field, tal vez crear una clase derivada puede tener algunos beneficios con respecto a la capacidad de mantenimiento de su código.
Depende de la presencia / falta de evolución del objeto: si desea un caso especial, la subclasificación o la inyección (DI) "select" comportamiento (estrategia) es buena.
Pero si también quiere permitir que Field_List cambie su comportamiento de forma dinámica, entonces la propiedad o el método de mutación es la única manera de hacerlo.
Ejemplo: pantalla de registro con diferentes "planes": básico, donde solo puede seleccionar una cosa y premium, donde puede seleccionar todo lo que desee. El cambio de plan cambiará entre las casillas de verificación desplegables y múltiples, a la vez que tendrá el mismo objeto, incluido su contenido.
Yo votaría por la propiedad / método de mutación.
Echa un vistazo a los principios de SOLID . Te ayudarán en tus diseños. En particular, el principio de responsabilidad única le indicará que no mezcle las dos preocupaciones en una clase, y el principio de sustitución de Liskov le indicará que no cree subclases que rompan el contrato de las superclases, como lo que también propone.
Entonces, ¿cuál sería la solución en tu caso? Podría crear una clase base abstracta que sería independiente del tipo de selección y luego crear 2 subclases, una para selección única y otra para selección múltiple.
Personalmente me gustaría ir por el modo Multiple_Choice_List_Field . No creo que haya un estándar estricto o un principio de ingeniería que haga que lo hagas de una manera en lugar de otra. Lo más importante aquí es elegir una forma de hacerlo y seguirlo cuando se encuentre con un dilema de este tipo. Debes ser consistente, pero a dónde vayas es tu propia elección.
Elegiría la subclase porque de esta manera no tendrá que List_Field su clase List_Field con verificaciones y requisitos adicionales. Por supuesto, hay otras consideraciones, por ejemplo, si necesita cambiar la opción múltiple y la opción única en el tiempo de ejecución, sería mejor optar por la propiedad booleana (aunque la subclase funcionará también, pero no me parece natural).
La otra cosa es que para List_Field es posible que necesite más de una propiedad para manejar múltiples opciones, dependiendo de su implementación actual. Por ejemplo, una nueva propiedad para devolver una matriz de los elementos seleccionados.
Simplemente hágalo de la forma que le resulte más cómodo para construir y mantener (y eventualmente extender).
Personalmente, yo diría que ninguno de los dos: en su lugar, use un constructor que tome multiple_choice_allowed, y luego tenga una propiedad que muestre ListFields como una colección (con solo un elemento cuando solo se permite uno, todos cuando se permite más de uno). Hágalo de solo lectura (lo que significa que debe copiarlo cada vez que devuelva la lista).