¿Convención de nomenclatura adecuada para un tipo de delegado .NET?


82

Por convención, las clases a menudo se nombran como sustantivos, métodos como verbos e interfaces como adjetivos.

¿Cuál es la convención de nomenclatura común para un delegado? ¿O cuál es una buena manera de diferenciar su nombre cuando los delegados se enumeran entre tipos y otras cosas?

Mi suposición inmediata es nombrar a un delegado más probablemente un adjetivo porque una interfaz de método único a menudo se puede reemplazar con un delegado.

Algunos pensamientos:

delegate object ValueExtracting(object container);

delegate object ValueExtractor(object container);

delegate object ValueExtractionHandling(object container);

delegate object ValueExtractionHandler(object container);

Respuestas:


111

Personalmente utilizo un par de patrones diferentes:

[Task][State]Handler - UITaskFinishedHandler

[Event]Handler - ControlLoadedHandler

[Function Name]Delegate - DoSomeWorkDelegate : se usa cuando necesito crear un delegado para llamar a una función en un hilo diferente / nuevo

[Task]Callback - ContainerLoadedCallback : se usa cuando el control A inicia una acción en la que el control B hace la mayor parte del trabajo y el control A ha pasado una dependencia al control B (es decir, ControlA puede haber pasado un contenedor de IU para que ControlB lo llene y necesita una notificación para mostrar realmente el contenedor )

Cuando tiene un proyecto que usa muchos subprocesos múltiples o llamadas WCF asíncronas, puede terminar con muchos delegados flotando, por lo que es importante adoptar un estándar que al menos tenga sentido para usted.


+1 Es una bonita convención. También estoy de acuerdo con la respuesta de @Aaronaught a continuación, donde un delegado usa por un tipo de evento debe tener el sufijo 'EventHandler' en lugar de solo 'Handler'.
Samuel

1
"Delegado de [nombre de función]" infringe CA1711, lamentablemente. Me gusta usar "[Nombre de función] Func" o "Acción [Nombre de función]" dependiendo de si tiene un tipo de retorno o no.
Tinister

1
Esa es probablemente la convención más útil (y más corta) que he visto hasta ahora. +1 de mi parte. Gracias por compartir @slugster
FullStackForger

Las reglas del código le dicen que no agregue el
Christian Findlay

2
@MelbourneDeveloper dice que los chicos que crearon el RequestDelegatepara asp.net-core; -]
t3chb0t

48

Las Pautas de diseño de marcos de Microsoft, el almanaque de nomenclatura para mí, dice lo siguiente sobre el tema:

√ SÍ agregue el sufijo "EventHandler" a los nombres de los delegados que se utilizan en los eventos.
√ Añada el sufijo "Devolución de llamada" a los nombres de los delegados que no sean los que se utilizan como controladores de eventos.
X NO agregue el sufijo "Delegado" a un delegado.


16
Es curioso que MS diga 'NO agregue el sufijo "Delegado" a un delegado', pero en este ejemplo tienen un delegado llamado ProcessBookDelegate...
PadawanLondon

@PadawanLondon la misma historia con RequestDelegateen asp.net-core - tanto a las convenciones de coherencia y codificación. Supongo que ni siquiera leen sus propios documentos.
t3chb0t

16

Dado que un delegado es algo que realiza una acción (un verbo), el delegado debe llamarse como llamarías a algo que realiza esa acción. Tomemos Converter<TInput, TOutput>por ejemplo. El verbo es Convertir . Lo que hace la conversión se llama convertidor , de ahí el nombre del delegado.


6

Esto depende de algunas cosas.

Si el delegado se va a utilizar como un evento, siempre debe denominarse EventHandlersubtipo, por ejemplo:

public delegate void ValueExtractingEventHandler(object sender,
    ValueExtractingEventArgs e);

Si no es un evento, entonces las pautas de codificación de MS (de las que nunca parece encontrar la copia correcta en Google) recomiendan explícitamente no incluir palabras como "delegado" o "controlador" en el nombre del delegado, excepto en el caso especial de EventHandlertipos.

Normalmente, los delegados deben tener nombres de acciones , que serían como ValueExtracting(si el delegado ocurre antes de que se extraiga el valor) o ValueExtracted(después de la extracción).

La Func<T1, T2, ..., TResult>sintaxis de delegado también se está volviendo más común, pero a menos que tenga 4 o más parámetros, no necesita declarar el suyo en absoluto, solo use uno existente:

object ExtractObject(object source, Func<object, object> extractor);

Esta sintaxis es mejor cuando el delegado se utiliza como cierre . El delegado en sí no tiene un nombre muy interesante, pero el argumento es un sustantivo de agente (extractor, proveedor, evaluador, selector, etc.)

La mayoría de los usos de los delegados encajan en una de las categorías anteriores, así que averigüe para cuál se está usando, elija apropiadamente.


3

Nunca pensé en ello, sobre todo porque sólo tiene que utilizar uno de los EventHandler<T>, Func<T>o Action<T>sobrecargas y nunca molesto en la definición de la mía. Probablemente elegiría ValueExtractor de los que ha enumerado. Esto hace que suene más como un objeto, y cuando lo invoques, lo usarás para realizar una acción. Por ejemplo:

ValueExtractor extractor += Blah;
var value = extractor(data);

Además, la mayoría de los delegados integrados también se nombran como sustantivos. En caso de duda, siga el marco .NET.


0

Yo iría con ValueExtraction ...
Nunca pensé por qué, pero supongo que porque estás almacenando una operación y debería ser un sustantivo ... estrictamente esto no es una operación, lo sé ...


0

Según Enumerable.Sum, pasaría al delegado como Func<object, object>y nombraría el parámetro selector:

void Foo(Func<object, object> selector) ...

Si tiene que crear su propio delegado para ello, lo aceptaría, ValueExtractorya que ese es el nombre más descriptivo de lo que hace.


Estos delegados genéricos (Action y Func) están bien en el 95% de los casos. Sin embargo, hay algunos casos en los que son tremendamente insuficientes, es decir, cuando el delegado tiene una firma complicada Y se pasa mucho. Básicamente, lo que hace cada argumento debería ser obvio, si no lo es, hacer un delegado nombrado es una buena idea.
Matěj Zábský
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.