Reutilización de código, mantenimiento de aplicaciones (II)
Introducción
Como vimos en el artículo inicial, nos encontramos con un problema sencillo de resolver pero que poco a poco se iba retorciendo o complicando.
Inicialmente teníamos en mente la lectura de un fichero de texto y la escritura de una información determinada después de procesarla en un fichero de texto.
Sin embargo, los requisitos cambian y ahora se nos pide que además de leer y escribir un fichero de texto, hagamos lo mismo pero con un fichero de Excel.
En realidad sería hacer algo similar a lo siguiente:
Implementación de la solución
Suponiendo que tengamos toda la lógica en nuestro formulario de prueba (igualmente ocurriría si tuviéramos toda la lógica implementada en una biblioteca de clases aunque los problemas estarían más acusados en el caso de tener todo implementado la interfaz de usuario), el código quedaría en este caso de la siguiente manera:
1: namespace UI_Sample
2: {
3:
4: using System;
5: using System.Collections.Generic;
6: using System.ComponentModel;
7: using System.Drawing;
8: using System.Windows.Forms;
9:
10: public partial class MainForm : Form
11: {
12:
13: public MainForm()
14: {
15: InitializeComponent();
16: // Por defecto es un fichero de texto.
17: this.EsTexto = true;
18: } // MainForm Constructor
19:
20: public bool EsTexto { get; set; }
21:
22: private void btnSampleTest_Click(object sender, EventArgs e)
23: {
24: string data = String.Empty;
25: if (this.EsTexto)
26: {
27: // Texto
28: data = ReadText();
29: // Hacemos algo con el texto leído.
30: // ...
31: // Escribimos el resultado del supuesto proceso anterior.
32: WriteText();
33: }
34: else
35: {
36: // Excel
37: data = ReadExcel();
38: // Hacemos algo con la información leída.
39: // ...
40: // Escribimos el resultado del supuesto proceso anterior.
41: WriteExcel();
42: }
43: // Mostramos un mensaje en pantalla tipo fake.
44: MessageBox.Show(
45: data +
46: Environment.NewLine +
47: "Lectura y escritura realizada.");
48: } // btnSampleTest_Click
49:
50: private string ReadText()
51: {
52: // Abrimos el fichero y leemos su contenido.
53: return "Texto leido";
54: } // ReadText
55:
56: private void WriteText()
57: {
58: // Escribimos el fichero en su lugar destino.
59: } // WriteText
60:
61: private string ReadExcel()
62: {
63: // Abrimos Excel y leemos su contenido.
64: return "Excel leída";
65: } // ReadExcel
66:
67: private void WriteExcel()
68: {
69: // Escribimos el Excel en su lugar destino.
70: } // WriteExcel
71:
72: } // MainForm
73:
74: } // UI_Sample
Posibles problemas
Aunque lo esté exagerando un poco, la idea es la de presentar delante nuestra diferentes problemas cotidianos con los que podemos encontrarnos a la hora de desarrollar una solución a un problema planteado.
En este caso, vemos que el código se está empezando a volver insoportable de mantener.
En este punto, tenemos una variable booleana que nos va a permitir discriminar entre un fichero de texto y un documento Excel.
No siendo la mejor de las soluciones, es hasta cierto punto aceptable.
Sin embargo, ¿qué ocurre si además de Excel y texto necesitamos acceder a la información de una tabla por ejemplo para leer determinada información, procesarla y volver a almacenarla en otra tabla?.
Bien, nuestra propiedad bool la podemos hacer nullable y así tendremos tres valores, true, false y null.
Posible chapuza a la vista aunque bien, es una posible solución.
Otra posible solución es crear una lista enumerada y a partir de ella determinar el tipo de origen, destino que queremos utilizar.
Es quizás una solución más elegante.
Otra es crear una llamada por cada tipo y que se cree el objeto de cada tipo para el objetivo de nuestra aplicación, y bien… quizás así podamos llevar a cabo una solución más o menos gloriosa.
De hecho, en la próxima entrega voy a ajustar todo esto que estoy comentando para sacar adelante algo que resulte un poco más claro a la hora de leer el código… a ver si lo logro y seguimos avanzando viendo problemas y posibles soluciones.
Hasta la próxima entrega… 🙂
One Responseso far
También considero interesante el tema de la compartición – reutilización de código en el mantenimiento de aplicaciones.
Por ejemplo, este caso: se tiene una versión para .net 3.5 y .net 4.0.
Un csproj compilado en .net 3.5 y otro csproj compilado en .net 4.0.
El código fuente está en el proyecto de .net 4.0.
El csproj de .net 3.5 tiene «Links» a los ficheros de código fuente del csproj de .net 4.0.
El problema viene en casos que se utilizan cosas específicas de .NET 4.0, como String.IsNullOrWhiteSpace.
En este caso, ya no compilaría el csproj de .net 3.5.
protected void BtnSSO_Click(object sender, EventArgs e)
{
var tok = new InfoToken();
tok.Idempresa = Convert.ToInt16(this.txtempresa.Text);
tok.IdApp = 4;
tok.Login = (String.IsNullOrWhiteSpace(this.txtUsuario.Text) ? «loginTest» : this.txtUsuario.Text.Trim());
tok.Url = CmbLstUrl.SelectedValue;
…
}
Estaría bien plantearse las alternativas a este caso.
Saludos.