Refactorización Guardia cláusulas

Question

¿Qué enfoques qué la gente toma (si lo hay) en la gestión de explosión en sus clases ? Por ejemplo:

public void SomeMethod<T>(string var1, IEnumerable<T> items, int count)
{
    if (string.IsNullOrEmpty(var1))
    {
        throw new ArgumentNullException("var1");
    }

    if (items == null)
    {
        throw new ArgumentNullException("items");
    }

    if (count < 1)
    {
        throw new ArgumentOutOfRangeException("count");
    }

    ... etc ....
}

En el proyecto que estoy trabajando actualmente en hay muchas clases que tienen un conjunto similar de cláusulas de guardia en los métodos públicos.

Soy consciente de los .NET 4.0 Code Contracts sin embargo, esto no es una opción para nuestro equipo en este momento.

Answer 1

Una gran cantidad de proyectos que he visto utilizar una clase Guard estática.

public static class Guard {
    public static void ArgumentIsNotNull(object value, string argument) {
        if (value == null)
            throw new ArgumentNullException(argument);
    }
}

Esto hace que el código mucho más limpio, en mi opinión.

Guard.ArgumentIsNotNull(arg1, "arg1");

Answer 2

Si no desea ir por la ruta contratos Código, una manera de simplificar es quitar las llaves:

public void SomeMethod<T>(string var1, IEnumerable<T> items, int count)
{
    if (string.IsNullOrEmpty(var1))
        throw new ArgumentNullException("var1");

    if (items == null)
        throw new ArgumentNullException("items");

    if (count < 1)
        throw new ArgumentOutOfRangeException("count");

    ... etc ....
}

Aparte de eso, hay algunas maneras que usted puede simular Code Contracts, si su objeción es que .Net 4.0 aún no es hora de máxima audiencia:

http://geekswithblogs.net/Podwysocki/archive/2008 /01/22/118770.aspx

Answer 3

Se podría considerar refactorización a Introducir un Null Object.

Answer 4

Mientras tanto hay un excelente artículo sobre esto aquí: http://haacked.com/archive/2013/01/05/mitigate-the-billion-dollar-mistake-with-aspects.aspx/

Yo consideraría usar NullGuard.Fody como estoy entusiasmado con capacidades Fodys para reducir código repetitivo

Answer 5

Un enfoque para reducir (no eliminar por completo) el número de cláusulas de guardia es entender la causa de su existencia. Muy a menudo, resulta que nos protegemos de los valores que son válidos para el tipo del argumento, pero no es válido para el método que los acepta. En otras palabras, se define método en un subconjunto del dominio definido por el tipo de argumento.

Solución a esta categoría de los casos es tratar de definir un subtipo (por ejemplo, una interfaz más restrictivo) y para aceptar ese tipo como argumento. Se puede encontrar un ejemplo ilustrativo en este artículo: ¿Por qué Debemos proteger las cláusulas?

Por supuesto, esta técnica no es aplicable a todos los casos. Todos los tipos de referencia, como mínimo permiten referencias nulas. En consecuencia, la mayoría de nuestros métodos se definirán en parte del dominio, que a su vez requiere una cláusula de guardia contra nulo.

Pero en el lado positivo, esta técnica ayuda a crecer el conocimiento de métodos que reciben argumentos que son más general de lo deseado. Fontanería ese agujero ayuda a mejorar el diseño en general.