c# validation guard-clause

c# - Cláusulas de la guardia de refactorización



validation guard-clause (5)

¿Qué enfoques toman las personas (si las hay) para manejar la explosión de la cláusula de guardia 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 en el que estoy trabajando actualmente hay muchas clases que tienen un conjunto similar de cláusulas de guardia en los métodos públicos.

Soy consciente de los Contratos de Código .NET 4.0, sin embargo, esta no es una opción para nuestro equipo en este momento.



Muchos de los proyectos que he visto usan una clase de Guard estática.

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

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

Guard.ArgumentIsNotNull(arg1, "arg1");



Si no desea ir por la ruta de los contratos de código, una forma de simplificarla es eliminar 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 formas en que puede simular los Contratos de Código, si su objeción es que .Net 4.0 no es el mejor momento todavía:

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


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

La solución a esta categoría de casos es tratar de definir un subtipo (por ejemplo, una interfaz más restrictiva) y aceptar ese tipo como argumento. Puede encontrar un ejemplo ilustrativo en este artículo: ¿Por qué necesitamos cláusulas de guardia?

Por supuesto, esta técnica no se aplica a todos los casos. Todos los tipos de referencia al menos 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 protección contra null.

Pero en el lado positivo, esta técnica ayuda a aumentar la conciencia de los métodos que reciben argumentos que son más generales de lo deseado. Fontanería que ayuda a mejorar el diseño en general.