Nadie dice que sea razonable pensar en métodos de una sóla línea, pero todos
sabemos que uno de 20 es mejor que uno de 200 ¿o alguien lo duda?
El caso es:¿por que no 10 en vez de 20? Y sólo 5? llevar la ídea al extremo y
pensar en métodos de una línea nos puede ayudar a aprender algo que luego
podamos aplicar en nuestros métodos de 100+ líneas.
(Mejor explicado en: http://blogs.msdn.com/jaybaz_ms/archive/2004/06/13/154918.aspx y
http://www.langrsoft.com/articles/smallMethods.shtml y
http://c2.com/cgi/wiki?LotsOfShortMethods )
Y por supuesto no estamos hablando de "concentrar" el código en una sóla
línea que haga muchas cosas (tipo cosas Perl o C++)
Ejemplos
En las pruebas unitarias de la EnterpriseLibrary hay métodos de una línea:
[TearDown]
public void CleanOutDatabase()
{
backingStore.Flush();
}
[Test]
public void CanGetCountOfItems()
{
Assert.AreEqual(0, backingStore.Count);
}
Y una clase de código de producción de entlib con métodos de una sóla línea
namespace Microsoft.Practices.EnterpriseLibrary.Caching
{
internal class StartScavengingMsg : IQueueMessage
{
private BackgroundScheduler callback;
public StartScavengingMsg(BackgroundScheduler callback)
{
this.callback = callback;
}
public void Run()
{
callback.DoStartScavenging();
}
}
}
El otro día viendo el código de BTSUnit nos encontramos con la clase.
public class StreamFromString : MemoryStream
{
public StreamFromString(string input) : base(Encoding.UTF8.GetBytes(input))
{
}
}
Que no tiene más métodos que el constructor con una sóla línea.
Mi conclusión personal, es que siempre que me encuentro con métodos de
pocas líneas suelen representar un buen diseño.
Por otro lado, pensar en que la recomendación "muchos métodos cortos mejor
que pocos métodos largos" no creo que haga daño a nadie y es el primer paso
para realizar la transición entre programación estructurada y OO.
Normalmente no es fácil preveer a priori el número de clases que vamos a
necesitar para implementar una determinada funcionalidad, siempre se puede
empezar con una clase a la que añadir una gran método, después partirlo más
métodos y cuando tenga muchos agruparlos en clases, después de unos pocos
Refactorings se puede ir "moldeando" el diseño, con el número de clases por
assembly, métodos por clase, y líneas por método justos y necesarios para
expresar el dominio del problema con código que funcione
Clean code that works !!