mvc - patron mvp c#
¿Es este un patrón de diseño bien conocido? ¿Cual es su nombre? (8)
He visto esto a menudo en el código, pero cuando hablo de él no sé el nombre para tal "patrón"
Tengo un método con 2 argumentos que llama a un método sobrecargado que tiene 3 argumentos y establece intencionalmente el tercero en una cadena vacía.
public void DoWork(string name, string phoneNumber)
{
DoWork(name, phoneNumber, string.Empty)
}
private void DoWork(string name, string phoneNumber, string emailAddress)
{
//do the work
}
La razón por la que hago esto es no duplicar el código y permitir que las personas que llaman todavía llamen al método que tiene solo 2 parámetros.
¿Es este un patrón, y tiene un nombre?
El nombre de eso es sobrecarga y no es un patrón de diseño sino una característica de POO
En realidad, es más que una simple sobrecarga de métodos (donde generalmente el mismo nombre de método tiene diferentes tipos de argumentos), este patrón específico, donde las sobrecargas son básicamente el mismo método, y el más corto invoca al más largo con un valor predeterminado para emular parámetros opcionales. se denomina patrón telescópico / telescópico, generalmente visto en constructores, pero, por supuesto, generalizable a cualquier método.
Para una cita más autorizada, aquí hay un extracto de Effective Java 2nd Edition , Item 2: Considere un patrón de constructor cuando se enfrenta a muchos parámetros de constructor ( extracto en línea )
Tradicionalmente, los programadores han usado el patrón de constructor telescópico , en el que usted proporciona un constructor con solo los parámetros requeridos, otro con un solo parámetro opcional, un tercero con dos parámetros opcionales, y así sucesivamente ...
De nuevo, generalmente el patrón telescópico se discute dentro del contexto de los constructores (donde, por ejemplo, un constructor de 2 argumentos tendría una línea this(arg1, arg2, ARG3_DEFAULT); para invocar al constructor de 3 argumentos, etc.), pero no lo hago. vea por qué no se puede generalizar a otros métodos también.
Otra cita autorizada, desafortunadamente sin una definición del patrón: Sun Developer Network: Cómo escribir comentarios de doc para la herramienta Javadoc :
Observe que los métodos y los constructores están en orden "telescópico", que significa la forma "no arg" primero, luego la forma "1 arg", luego la forma "2 arg", y así sucesivamente.
Y otra cita aleatoria, con una definición más explícita del patrón: ¡Estoy sobrecargando el método de odio (y tú también puedes hacerlo!) :
Métodos telescópicos
Puede tener una función que toma algunos argumentos. Es posible que los últimos argumentos no sean tan importantes, y la mayoría de los usuarios se sentirían molestos por tener que averiguar qué transmitirles. Así que creas unos cuantos métodos más con el mismo nombre y menos argumentos, que llaman al método "maestro".
Esta última cita propone directamente que el soporte de idioma para los argumentos predeterminados es una alternativa mucho mejor.
Es un ejemplo de un método de ayuda. La gente de Sheesh, no estar en el libro Gang of Four no impide que sea un patrón. En el caso específico donde el ayudante es público y el método ayudado es privado, es un ejemplo de encapsulación. Posiblemente un poco demasiado encapsulado en este caso.
Estoy de acuerdo con @polygenelubricants, pero me gustaría señalar que el patrón telescópico se puede usar además de la sobrecarga. Un ejemplo es en Objective-C, donde los selectores de métodos (firmas) deben ser únicos y no se pueden sobrecargar.
- (id)init {
return [self initWithParam:0];
}
- (id)initWithParam:(int)param {
// Do real initialization here!
return self;
}
No, este no es un patrón de diseño en la cuadrilla de cuatro sentidos, pero es común en muchos idiomas que no permiten parámetros predeterminados.
En un lenguaje como ruby, podrías hacer algo similar como sigue
def dowork(name, phoneNumber, emailAddress = '''')
# code here
end
Se llama como Sobrecarga de funciones. En la sobrecarga de funciones, el nombre de una función es el mismo, pero difiere en el tipo de parámetro o en el número de parámetros. También se le llama como falso polimorfismo. No es un patrón, es un concepto básico de POO.
Supongo que sus métodos DoWork deberían llamarse CreateContact o su llamada a CreateContact debería ser DoWork ...
Pero esto no es realmente un patrón. Es solo un uso común de la sobrecarga de métodos .
Yo diría que esto es bastante ac # <4 por falta de argumentos predeterminados. Si prescribes la escuela de pensamiento ''me faltan patrones en las características del lenguaje'', supongo que podrías decir que es un patrón, aunque no el que comúnmente se nombra.
edit: ok tu actualización realmente me ha lanzado, no veo qué estás tratando de hacer con un método público llamando a un método privado. En lo que respecta a la API pública, puede mover todo el código de los métodos privados al método público y tener una variable local para el valor ''predeterminado''. ¿O son ambos métodos también llamados de otros lugares en la clase?