Más fluido C#/.NET

Question

Un compañero de trabajo mío se le ocurrió esto y me pregunto qué piensan los demás? Personalmente, me parece interesante, pero me pregunto si es una gran partida. Ejemplos de código a continuación. Métodos de extensión en la parte inferior.

Pensamientos generales por favor. ¿Otros métodos de extensión que podrían agregarse?

var ddl = Page.FindControl("LocationDropDownList") as DropDownList; 

ddl.Visible = true; 
ddl.SelectedValue = "123"; 

if(isAdmin) 
    ddl .SelectedValue = "111"; 

se convierte en:

Page.FindControl("LocationDropDownList") 
    .CastAs<DropDownList>() 
    .With(d => d.Visible = true) 
    .With(d => d.SelectedValue = "123") 
    .WithIf(isAdmin, d => d.Items.Add(new ListItem("Admin", "1"))); 

O:

Page.FindControl("LocationDropDownList") 
     .CastAs<DropDownList>() 
     .With(d => 
     { 
      d.Visible = true; 
      d.SelectedValue = "123"; 
     }) 
     .WithIf(isAdmin, d => d.SelectedValue = "111"); 

Los métodos de extensión:

public static TResult CastAs<TResult>(this object obj) where TResult : class 
{ 
    return obj as TResult; 
} 

public static T With<T>(this T t, Action<T> action) 
{ 
    if (action == null) 
     throw new ArgumentNullException("action"); 

    action(t); 

    return t; 
} 

public static T WithIf<T>(this T t, bool condition, Action<T> action) 
{ 
    if (action == null) 
     throw new ArgumentNullException("action"); 

    if (condition) 
     action(t); 

    return t; 
} 

Answer 1

Entre mis reglas generales para escribir código claro está: poner todos los efectos secundarios en las declaraciones; las expresiones de no declaración no deberían tener efectos secundarios.

Su primera versión del programa sigue claramente esta regla. La segunda versión claramente lo viola.

Una idea adicional: si tuviera que leer código como el código que ha mostrado, naturalmente asumiría que el propósito del código era construir una estructura evaluada perezosamente que representara esas operaciones - esto es exactamente por qué las comprensiones de consulta en C# 3 se construyen de esta manera. El resultado de la expresión de consulta es un objeto que representa la aplicación diferida de la consulta.

Si su intención es captar la noción de "ejecutar estos efectos secundarios de manera diferida en un momento posterior de mi elección", entonces este es un enfoque sensato. Esencialmente, lo que estás construyendo es una mónada de efecto secundario. Si su intención es simplemente proporcionar una sintaxis diferente para el código ejecutado con impaciencia, entonces esto es simplemente confuso, prolijo e innecesario.

Answer 2

veo ninguna ventaja a este que además de ser confuso para el lector. Con respecto a mi contendiente, me gustaría saber en qué planeta es más legible. Por lo que puedo decir, la primera versión tiene una legibilidad más o menos perfecta, mientras que es bastante legible, pero hace que el lector se pregunte si hay alguna magia extraña dentro de With y WithIf.

En comparación con la primera versión, es más larga, más difícil de escribir, menos obvia y de menor rendimiento.

Answer 3

¡Esto es un abuso de método de extensión si alguna vez lo vi!

Answer 4

Supongo que no puedo ver lo que las nuevas versiones te dan. El original es bastante claro y es menos prolijo. Yo diría que sería más rápido también. Evitaría usar (¿abusar?) Funciones de lenguaje como esta a menos que haya un claro beneficio.

Answer 5

Son solo diferentes estilos de codificación, ¿qué quiere decir con "partida demasiado grande"? ¿Salida de qué? De lo que estás acostumbrado? Solo tú puedes decidir eso. Diré que el bloque With de VB ha hecho más daño que bien a la legibilidad del código, y no trataría de replicar el comportamiento en C#, pero eso es solo mi preferencia.

que casi siempre lo uso para FindControl (sí, inflexible a RepeaterItem, no tiene por qué ser, pero esa es la única cosa que siempre lo uso para todos modos):

public static T FindControl<T>(this RepeaterItem item, string id) 
{ 
    return item.FindControl(id) as T; 
} 

e invocar que de este modo:

Literal myLiteral = e.Item.FindControl<Literal>("myLiteral"); 

Answer 6

Mis 2 centavos: se ve bien, mi único comentario es que "con el" tipo de implica algo así como "¿Dónde" o "que tiene" cuando se está configurando en realidad una propiedad. Sugeriría un nombre de método de algo como "Hacer", "Ejecutar" o "Establecer", pero quizás sea solo mi extraña visión del mundo.

¿Qué tal:

Page.WithControl<DropDownList>("LocationDropDownList") 
    .Do(d => d.Visible = true) 
    .Do(d => d.SelectedValue = "123") 
    .DoIf(isAdmin, d => d.Items.Add(new ListItem("Admin", "1"))); 

Answer 7

digo palo con la primera versión sin los métodos de extensión o expresiones lamba. Estos son conceptos relativamente nuevos, por lo que no muchos desarrolladores tendrán un control sobre ellos fuera de su uso en la recuperación/manipulación de datos de una base de datos. Si los usa puede tener un golpe en el costo de mantenimiento. Es agradable decir "lee si esto es griego para ti"; pero en la vida real ese puede ser el mejor enfoque.

Answer 8

Estoy más cómodo con la primera versión. Toma menos tiempo para leer y entender. Estoy de acuerdo en que los métodos de extensión también están bien si está familiarizado con él y también está familiarizado con el método With, pero ¿cuál es el beneficio de este en este caso?

Answer 9

Es un uso interesante de las extensiones, y lo aprecio solo por ese mérito. No estoy seguro de que lo use, pero si a su equipo le gusta, entonces por supuesto, úselo.

Answer 10

Un voto más para "no útil". El método de extensión With no hace nada excepto resumir sentencias secuenciadas con un método. C# ya tiene una función incorporada para las instrucciones de secuenciación, se llama ;.

De forma similar, el WithIf ajusta un enunciado if sin ninguna modificación al flujo de control. Desde mi punto de vista, solo te estás invitando a métodos como:

public static T For<T>(
    this T t, int start, Func<int, bool> cond, Action<T, int> f) 
{ 
    for(int i = start; cond(i); i++) 
    { 
     f(t, i); 
    } 
    return t; 
} 

Answer 11

Yo diría que sigas con la primera versión. Lo que has publicado es demasiado inteligente para ser inmediatamente útil para alguien que lee el código.

Usted podría incluso ir un paso más allá y acabar con eso "var":

DropDownList ddl = (DropDownList) Page.FindControl("ddlName"); 

Answer 12

que predicen toda la moda "interfaz fluida" será la "notación húngara" de la década de 2000. Personalmente creo que no se ve muy limpio y corre el riesgo de volverse muy inconsistente si tiene múltiples desarrolladores, cada uno con sus propias preferencias.

Answer 13

El original es más legible.

El cambio de API sencilla sería la de hacer que el objeto devuelto por FindControl() una cosa del constructor-esque (donde vuelven todos los métodos set 'esto'):

Page.FindControl("LocationDropDownList") 
    .setVisible(true) 
    .setSelectedValue(isAdmin ? "111" : "123"); 

Answer 14

Parece que su compañero de trabajo es una Lambda Junkie.

Answer 15

Creo que la cuestión de la legibilidad es subjetiva y personalmente no tengo ningún problema con lo que has hecho. Consideraría usarlo si su organización lo "aprobó".

Creo que el concepto es correcto y si cambió "Con" a "Deje" sería más "funcional" o "F # -ish". Opinión personal.

Page.FindControl("LocationDropDownList")  
    .CastAs<DropDownList>()  
    .Let(d => d.Visible = true) 
    .Let(d => d.SelectedValue = "123"); 

Answer 16

Nota mínima. Por experiencia personal, que cambiaría:

if(isAdmin) 
    ddl.SelectedValue = "111"; 

a

if(isAdmin) { 
    ddl.SelectedValue = "111"; 
} 

o

if(isAdmin) 
{ 
    ddl.SelectedValue = "111"; 
} 

Esto le ahorrará tiempo en la depuración tarde o temprano.

Answer 17

Si esto fuera un función idioma:

With(Page.FindControl("LocationDropDownList") as DropDownList) 
{ 
    Visible = true; 
    SelectedValue = "123"; 
    if(isAdmin)  
     Add(new ListItem("111")); 
} 

Se podría ganar algo:

• redundancia evitar del objeto mutado
• todas las características del lenguaje disponibles en el "con" bloque

Above tries emular el estilo sin cosechar los beneficios. Cargo Cult.

(Nota: Me hago entender los diversos argumentos en su contra, pero todavía estaría bien)

---

Por cierto, algunos de mi C++ Win32 interfaz de usuario Ayudantes contienen emisores que utilizan el encadenamiento similares lo que desea lograr:

LVItem (m_lc, idx) .SetText (_T ("Hola")). SetImg (12) .SetLParam (id);

En ese caso, al menos gano "sin redundancia", pero eso se debe a que no tengo propiedades.

Answer 18

Este es un caso de aprendizaje perfecto sobre cómo hacer algo más complicado de lo que debe ser.

La primera versión es clara y no requiere conocimiento adicional más allá de las construcciones de lenguaje normal.

Answer 19

En cuanto a una "Interfaz fluida" C# ya tiene una gran sintaxis para inicializadores que es (en mi humilde opinión) mejor que tratar de usar el estilo fluido. Por supuesto, en su ejemplo no está inicializando un nuevo objeto, está cambiando uno existente. Toda mi experiencia con interfaces fluidas proviene de una segunda exploración de wikipedia 30, pero creo que la respuesta de JeeBee es más en el espíritu de la programación Fluido, aunque podría cambiar las cosas un poco:

Page.FindDropDownList("LocationDropDownList")  
    .setVisible(true)  
    .setAdminSelectedValue("111") 
    .setSelectedValue("123") 

Se podría argumentar que esto es más legible, especialmente para un idioma sin propiedades, pero todavía creo que no tiene sentido en C#.

Answer 20

En ciertas circunstancias cuidadosamente interfaces fluidas construida puede ser muy útil. En primer lugar, dado que el desarrollador tiene un número limitado de opciones, son (típicamente) fáciles de usar y difíciles de usar de forma incorrecta. En segundo lugar, debido a la estructura de tipo oración, pueden ser una manera agradable y limpia de declarar sus intenciones, especialmente cuando se construyen objetos complejos.

he encontrado interfaces fluidas a ser muy útil en el desarrollo de código de prueba en el que a menudo es necesaria la construcción de una gran cantidad de objetos de dominio con ligeras variaciones. También los utilicé con éxito como una forma de presentar el patrón del decorador y eliminar la excesiva sobrecarga de métodos.

Si alguien está interesado en aprender más sobre interfaces fluidas, sugiero que veas este work in progress por Martin Fowler.

Answer 21

buena regla de oro:

Si su primera impresión de su código es "Este es inteligente" - no es probablemente una buena idea.

El código correcto debe ser simple, legible, y solo "inteligente" si es absolutamente necesario.