Enunciado: Quiero leer un DataTable, seleccionar un conjunto de filas y devolverlo a la función que me ha invocado.
Primera aproximación. Obtengo una colección de filas con un .select() y las .add en un nuevo DataTable. MECK!! Error, eso no se puede hacer sin liarte con clonaciones y demás gaitas.
Segunda aproximación. Obtengo un DataView del DataTable filtrado en la instanciación por medio del rowFilter. MECK!! Me obliga a cambiar todo el código que utilice este método y que espere un DataTable.
Aproximación y resolución:
///
/// Devuelve el DataTable filtrado obtenido de la fuente de datos.
///
///
public DataTable leeTablaFiltrada()
{
DataTable tabla = new DataTable();
tabla = leeTabla(); // Función que recupera el DataTable de la fuente de datos.
DataView vista = new DataView(tabla, "
// Tener cuidado de si la condicion de filtro es un string ponerlo entre comillas simples
return vista.ToTable(); // Este es el "milagro"
}
Moola!!
8 comentarios:
Je, je... no he podido resistirme... :-)
Si leemos atentamente el comentario del método, quizás podríamos renombrar dicho método a leeTablaFiltradaDesdeFuenteDeDatos(DataSource unaFuenteDeDatos).
De esta manera, si atendemos también al comentario que acompaña a la linea que dice:
tabla = leeTabla(); // Función que recupera el DataTable de la fuente de datos
quizás también podríamos escribir:
tabla = leeTablaDesdeFuenteDeDatos(unaFuenteDeDatos)
¿Qué nos ahorramos? Comentarios que no hay que mantener sincronizados con el código a lo largo del tiempo.
¿Qué ganamos? Que el método ahora es independiente de si ese DataSource es real o es una simulación (mock).
Je, je, de verdad que no he podido evitar hacer el comentario. :-D
1. Este código está sobrecomentado para que lo pueda leer mis "target" de lectores: yo mismo (y mi memoria de pez) y gente de muy poquito nivel o noveles.
2. Lo que dices es espantoso y te olvidas de la ley de oro "los comentarios no compilan". Osea, en vez de una línea de comentario que no "pesa" ni al verificar, analizar y compilar el código, quieres meter un nombre de método larguísimo que no sabes donde va a ser reutilizado y si se va convertir en un línea de 500 caracteres inmanejable (lo más seguro, con dos métodos con descripciones como dices ya es inmanejable).
3. Mantener los comentarios es intrinseco a su uso. Es como decir que no hay que hacer pruebas unitarias porque al modificar el método hay que mantenerlas y modificarlas.
No te resistas... conoce el poder del lado oscuro de la fuerza!! XD
Vale, me rindo, dejaré que te consumas en las llamas del mantenimiento de código desactualizado. :-)
Pero antes, dos cositas:
* Avoid Obsolete Comments by UncleBob
* Writing Testable Code by Misko Hevery
Por mucho Bob, a mí un "iluminado" me borra los comentarios y lo sacod e mi equipo.
Que no los pongas, ya me parece muy malo por la insolidaridad que implica (el siguiente DEBE ser al menos tan bueno como el). Pero que en vez de actualizarlo lo borre, es inaceptable.
Para él el código es limpio y lo lee de muerte, pero si viene una persona acostumbrada a otro lenguaje, o muy novato o este pequeño código es parte de un proceso con decenas de métodos, clases y situado en diferentes páginas, ya me dirás cuanto tardaría en saber qué demonios hace el proceso.
Arrogante, presuntuosa y anglocentrista es esta regla C2 del código limpio.
En la REALIDAD el código es tan complejo, retorcido, profundo y contradictorio que sin comentarios vas perdido.
¿Cómo quita describe la funcionalidad sin comentarios en caso de sobrecargas?
Pero hombre, Juan Carlos, que TU realidad esté llena de código basura (repletito de comentarios, eso sí) no la hace más válida que SU realidad (la de UncleBob) que está llena de código con métodos cuyo nombre explica claramente su intención y, por tanto, no requiere comentario añadido que potencialmente puede quedar obsoleto (porque TODOS somos humanos).
Sinceramente, con todo el afecto, creo que tu código es retorcido porque no haces (o no puedes hacer) el esfuerzo de limpiarlo. Pero debes reconocer que si el código está limpio (está bien estructurado, los niveles de abstracción están bien balanceados, los nombres están bien elegidos, son autoexplicativos...) entonces no son necesarios los comentarios en el código porque son potenciales fuentes de confusión y, por tanto, de errores.
1. No es MI realidad, es NUESTRA realidad. Que tu y yo estamos en el mismo mundo. Y Bob también. El mismo código del artículo, a mi me cuesta entenderlo y el comentario, aunque obsoleto, me dió una pista para entenderlo en medio segundo. Me ajustó el foco. Me ayudó mucho. No tuve que tirar del manual de Java para saber qué hacian esos métodos.
2. ¿Mi código no es limpio? No, yo argumento que tus conocimientos no son suficientes para entenderlo. Y ante la duda de cual de las dos partes puede tener la razón, se ponen comentarios. Así el especialista lo puede leer obviando los comentarios y el torpe puede saber de qué va la cosa.
3. Cualquier lenguaje de programación es fuente de errores y obsolencia. Ya deberiamos saber que el problema menor son los comentarios. El PROBLEMA es el código sin comentar que NADIE sabe qué es y NADIE se atreve a quitar.
4. Solamente el código compilable es fuente de errores. Un comentario canta por alegrias cuando es obsoleto o erroneo, pero no te rompe una build. El código, sea comentado o no, es el único que puede producir errores - que es lo que nos interesan evitar -.
5. Un comentario obsoleto o erroneo es una negligencia por parte del programador que lo hizo o lo actualizó. Del mismo mismo tipo del que hace "for x = 0" y después usa x para hacer cosas.
P.D. Tu argumentación es filosófica. Te invito a publicar un código de mil lineas (dividido como quieras) que sea autoexplicativo como para que poner comentarios sea superfluo.
P.D.D. Debes evitar las dependencias siempre que puedas. Propones, para aumentar la legibilidad del código, un parámetro a la función leeTabla() que es erroneo.
Primero porque en la llamada de un método no se puede definir libremente los parámetros que se envian, se definen en el método invocado. Y sin saber si acepta el parametro unaFuenteDeDatos, lo más seguro es que rompas el código.
Segundo, le creas una dependencia con el tipo unaFuenteDeDatos, haciendo el código menos eficiente y, sobre todo, llendo en contra de la POO en donde hay que buscar el menor acoplamiento posible.
"La resistencia es futil"
Creo que estoy de acuerdo con jose Manuel.
Y tambien estoy seguro que una clase con 1000 lineas y sin comentarios puede ser totalmente entendible sin ellos (con javadoc o similar por supuesto), como tambien estoy seguro de que una clase de 1000 lineas es bastante probable que se pueda dividir en varias clases con distinta responsabilidad que cooperen para conseguir el objetivo.
Todo eso si es POO, escribir una clase con 1000 lineas empieza a dejar de serlo.
Saludos
Para esto están los comentarios... no he hablado de una clase de 1000 lineas. Estamos de acuerdo que eso es una aberración. El ejemplo que he pedido, y que por supuesto no se puede realizar, es de de un código de 1000 lineas. Lo cual seguro que implica varias clases con varios métodos en varias páginas. Y que, sin comentarios, es un infierno.
No cambiemos las cosas que están negro sobre blanco... :)
P.D. La misma existencia de este debate es un sintoma clarísimo de la necesidad de los comentarios.
La conclusión que he llegado en este interesante debate es que ojalá no me encuentre nunca con código vuestro en donde tenga que hacer ingenieria inversa para intentar saber qué hace el código... :P
A mi el tema de repudiar los comentarios es un ejemplo calro del antipatron de "reinventar la rueda cuadrada".
Publicar un comentario