1. Charla de viejo
Delphi VS VC ya es un tema muy antiguo, pero todavía quiero hablar de ello aquí. Si no está de acuerdo, ríase.
Los beneficios de RAD son fáciles de ver. En términos de diseño de interfaz, Delphi es en realidad mejor que VC. Quiero escribir un botón transparente no convencional. En Delphi, solo necesito encontrar un control, hacer clic con el mouse y modificar el título. ¿Qué pasa con VC? Se necesitan al menos 10 líneas de código para hacerlo. Por supuesto, el enfoque de MFC hace que las personas comprendan los principios subyacentes de Windows, pero la encapsulación de programación orientada a objetos no se refleja bien. Los desarrolladores necesitan comprender todos los principios subyacentes antes de poder escribir código. Para mí y para la mayoría Ser principiante es una tortura porque no es necesario. Sí, los plazos de desarrollo siempre son ajustados y el tiempo nunca es suficiente. No podemos esperar que los programadores conozcan todos los aspectos de la programación de Windows. Algunas personas saben mucho sobre videos y otras son buenas en redes, pero nadie es polivalente y bueno. en todo no es realista, por lo que la encapsulación es muy importante. Si tengo que dedicar el 30% o más de mi tiempo a un botón transparente o a una hermosa interfaz cada vez que desarrollo un nuevo producto, entonces me lanzaré al río :) ¡De hecho, Delphi es mejor que MFC en términos de interfaz! Por supuesto, eso no significa que MFC no pueda diseñar interfaces hermosas, pero lleva demasiado tiempo y no vale la pena.
¿RAD realmente se trata de beneficios? Ni. Al menos no para los principiantes, porque hace que la gente malinterprete que la programación consiste solo en mover el mouse y tirar del marco. El resultado final es que la gente piensa que Delphi es solo para escribir interfaces y que la capa inferior no puede hacer nada. Parece que todos los programadores de MFC hablan de los programadores de Delphi: "Además de tener una interfaz hermosa, ¿qué más puede hacer su programa?" De hecho, aparte de DDK, ¿qué no se puede desarrollar en Delphi? ¿Qué archivo de encabezado API no tiene Delphi? Borland no se ha convertido, pero JEDI lo ha convertido. Incluso si JEDI no se ha convertido, es lo mismo si lo hace usted mismo. Siempre que me proporcione el archivo de encabezado C, puedo convertirlo. Las breves instrucciones de conversión en JEDI. Debería ser una documentación obligatoria para todo programador de Delphi. Una vez convertidos los archivos de encabezado, todo lo que queda es comenzar a escribir. ¡Lo que MFC puede hacer, Delphi también puede hacerlo! ¿video? ¿red? directox? ¿Audio? ¿Qué no puede hacer Delfos?
2. Subproceso
Al escribir un evento, muchas personas simplemente comienzan a escribirlo directamente, no importa cuánto tiempo dure el código o cuántas cosas se hagan, siempre que se haga en un evento, simplemente lo escriben en su cabeza. No tienen forma de comenzar a revisarlo unos meses después porque el fragmento de código es demasiado largo. Entonces, ¿por qué no separar los fragmentos de código? La atención humana es limitada y te sentirás mareado si lees más de 100 líneas de código de una vez. Los mayores de Delphi me dijeron una cosa: ¡todos los procesos (el proceso aquí incluye PROCEDIMIENTO y función) no deben exceder las 25 líneas! Debido a que esta longitud de código no le hará girar la cabeza, comprenderá fácilmente lo que está haciendo el proceso.
Entonces, ¿cómo se separan las cosas que se hicieron originalmente en un evento? Hay muchos métodos, mi experiencia es modular. Por ejemplo, si hay muchas cosas diferentes que hacer en un evento, las diferentes cosas se convierten en diferentes subprocesos y luego se llaman en el proceso principal. La mayoría de los procesos principales son algunos juicios y bucles, y habrá. No hay un proceso de implementación específico. Esto creará muchos fragmentos de código, ¡pero mantendrá tu atención!
Principio: Un proceso sólo hace una cosa y la hace bien.
Referencia: código fuente VCL. Si observamos el código fuente de VCL, ¡rara vez hay más de 25 líneas de código!
3. Nombre del parámetro
Recuerdo que cuando aprendí el SDK por primera vez, me sentí mareado cuando vi la notación húngara, ¡era demasiado! ¡No puedo recordarlo! Así que odio a ese inventor :) ¡Finalmente aparece Delphi y se acabaron los días de bailar con grilletes! En Delphi, definir una cadena con un nombre de variable como strDoSometing es ridículo e innecesario. Siempre que su procedimiento sea breve y no aparezcan variables globales, no necesita ese prefijo. Por ejemplo:
procedimiento SubPro;
var
yo: byte;
Ancho, Alto: entero;
comenzar
Ancho := ObtenerAncho;
Altura := ObtenerAltura;
para i:=0 a 9 hacer
comenzar
DrawThread := TDrawThread.Create;
DrawThread.Width:= Ancho;
DrawThread.Height: = Altura;
DrawThread.Inicio;
fin;
fin;
Creo que aunque dicho segmento de código no tenga comentarios, es fácil saber qué intenta hacer. Por lo tanto, elimine todos los prefijos y guiones bajos, ¡los programas Delphi no los necesitan! Nuestros nombres de parámetros solo necesitan verbo + sustantivo. Solo necesitamos explicar la función de este parámetro. No queremos cosas redundantes. La simplicidad es hermosa. La ventaja de Pascal es que el código parece hablar, en lugar de leerlo. En tu cabeza, lo que piensas es cómo se ve el código. Elegante y sencillo, estos son los beneficios de Pascal, ¡respételos!
Principio: ¡La simplicidad es hermosa!
4. Subventana
Muchas personas operan directamente los controles en la subventana cuando llaman a una subventana, como por ejemplo:
si SetAlarmParamDlg.ShowModal = MrOK entonces
comenzar
Horas de alarma := StrToInt(SetAlarmParamDlg.Edit1.Text);
Área de alarma := SetAlarmParamDlg.SpinEdit1.Value;
fin;
Dios mío, si mañana los usuarios piensan que el Edit o SpinEdit que usas se ve feo y lo reemplazan con un hermoso control, ¿qué harás? No solo necesita modificar el código de la subventana, sino que también necesita modificar el código del formulario principal. Por supuesto, un programa con una o dos subventanas no le causará ningún problema. ¿Qué pasa si es un programa con más de veinte subventanas? ¡Tardó un día, pero el motivo fue simplemente cambiar un control! ¿Por qué no probar con otro método? Si utiliza atributos para representar los parámetros que desea utilizar, guardará innumerables códigos.
//formulario principal
si SetAlarmParamDlg.ShowModal = MrOK entonces
comenzar
Horas de alarma := SetAlarmParamDlg.AlarmTimes;
Área de alarma := SetAlarmParamDlg.AlarmArea;
fin;
// subformulario
interfaz
privado
FAlarmTimes: entero;
FAlarmArea: entero;
publicado
propiedad AlarmTimes: entero leer FAlarmTimes escribir FAlarmTimes;
propiedad AlarmArea: entero leer FAlarmArea escribir FAlarmArea;
implementación
...
FAlarmTimes := StrToInt(Edit1.Text);
FAlarmArea := SpinEdit1.Value;
Resultadomodal := MrOK;
...
Mientras persista de esta manera, encontrará grandes beneficios. Una subventana solo hace lo suyo, y la interacción entre la ventana principal y ella se realiza a través de atributos, siempre que la interfaz permanezca sin cambios. La subventana no afectará a la ventana principal. No importa cómo se cambie la apariencia de la subventana, cómo se reemplacen los controles o cómo se modifique el código, todo el programa sigue siendo el mismo, solo ha cambiado la interfaz.
Principio: Modularice sus subventanas. Windows también son clases. La forma en que se comunican las clases debe ser la forma en que deben comunicarse las ventanas.