1. Conversa de velho
Delphi VS VC já é um assunto muito antigo, mas ainda quero falar sobre isso aqui. Se você não concorda, ria.
Os benefícios do RAD são fáceis de ver em termos de design de interface, o Delphi é realmente melhor que o VC. Quero escrever um botão transparente não convencional. No Delphi, só preciso encontrar um controle, clicar com o mouse e modificar a legenda. São necessárias pelo menos 10 linhas de código para fazer isso. É claro que a abordagem do MFC faz com que as pessoas entendam os princípios subjacentes do Windows, mas o encapsulamento da POO não é bem refletido. Os desenvolvedores precisam entender todos os princípios subjacentes antes de poderem escrever código. Para mim e para a maioria Ser iniciante é uma tortura porque não há necessidade. Sim, os prazos de desenvolvimento são sempre apertados e o tempo nunca é suficiente. Não podemos esperar que os programadores conheçam todos os aspectos da programação do Windows. Algumas pessoas sabem muito sobre vídeos e outras são boas em networking, mas ninguém é versátil e bom. em tudo. não é realista, então o encapsulamento é muito importante. Se eu tiver que gastar 30% ou mais do meu tempo em um botão transparente ou em uma interface bonita toda vez que desenvolvo um novo produto, então vou pular no rio :) O Delphi é realmente melhor que o MFC em termos de interface! Claro, isso não significa que o MFC não possa projetar interfaces bonitas, mas isso leva muito tempo e não vale a pena.
A RAD é realmente uma questão de benefícios? Nenhum. Pelo menos não para iniciantes, porque faz com que as pessoas entendam mal que programar é apenas mover o mouse e puxar o quadro. O resultado final é que as pessoas pensam que o Delphi serve apenas para escrever interfaces e que a camada inferior não pode fazer nada. Parece que todos os programadores MFC falam sobre os programadores Delphi: "Além de ter uma interface bonita, o que mais seu programa pode fazer de errado?" Na verdade, além do DDK, o que não pode ser desenvolvido em Delphi? Qual arquivo de cabeçalho da API o Delphi não possui? Borland não converteu, mas JEDI o converteu. Mesmo que o JEDI não tenha convertido, é o mesmo se você mesmo fizer isso, contanto que você me forneça o arquivo de cabeçalho C, posso convertê-lo. deve ser uma documentação obrigatória para todo programador Delphi. Depois que os arquivos de cabeçalho forem convertidos, tudo o que resta é começar a escrever. O que o MFC pode fazer, o Delphi também pode! vídeo? rede? directx? Áudio? O que o Delphi não pode fazer?
2. Subprocesso
Ao escrever um evento, muitas pessoas simplesmente começam a escrevê-lo diretamente, não importa quanto tempo o código seja ou quantas coisas sejam feitas, desde que seja feito em um evento, elas simplesmente anotam em suas cabeças. eles não têm como começar ao revisá-lo alguns meses depois, porque o trecho de código é muito longo. Então, por que não separar os trechos de código? A atenção humana é limitada e você ficará tonto se ler mais de 100 linhas de código de uma só vez. Os idosos do Delphi me disseram uma coisa: todos os processos (o processo aqui inclui PROcedimento e função) não devem exceder 25 linhas! Como esse comprimento de código não fará sua cabeça girar, você entenderá facilmente o que o processo está fazendo.
Então, como você desmonta as coisas que foram feitas originalmente em um evento? Existem muitos métodos, minha experiência é modular. Por exemplo, se há muitas coisas diferentes para fazer em um evento, então as diferentes coisas são convertidas em diferentes subprocessos e então chamadas no processo principal. A maioria dos processos principais são alguns julgamentos e loops, e haverá. nenhum processo de implementação específico. Isso criará muitos trechos de código, mas manterá seu foco!
Princípio: Um processo faz apenas uma coisa e faz bem.
Referência: código-fonte VCL. Olhando para o código-fonte da VCL, raramente há mais de 25 linhas de código!
3. Nome do parâmetro
Lembro que quando aprendi o SDK pela primeira vez, fiquei tonto ao ver a notação húngara, foi demais! Não consigo me lembrar disso! Então eu odeio aquele inventor :) Finalmente Delphi aparece e os dias de dançar algemados acabaram! No Delphi, definir uma string com um nome de variável como strDoSometing é ridículo e desnecessário. Contanto que seu procedimento seja curto e nenhuma variável global apareça, você não precisa desse prefixo. por exemplo:
procedimento SubPro;
var
eu: byte;
Largura, Altura: inteiro;
começar
Largura := ObterLargura;
Altura := GetHeight;
para i:=0 a 9 faça
começar
DrawThread := TDrawThread.Create;
DrawThread.Width := Largura;
DrawThread.Height := Altura;
DrawThread.Start;
fim;
fim;
Acho que mesmo que tal segmento de código não tenha comentários, é fácil saber o que ele está tentando fazer. Portanto, remova todos os prefixos e sublinhados, os programas Delphi não precisam deles! Nossos nomes de parâmetros só precisam de verbo + substantivo. Precisamos apenas explicar a função deste parâmetro. Não queremos coisas redundantes. A vantagem de Pascal é que o código parece estar falando, em vez de ler do céu. . Na sua cabeça, o que você pensa é a aparência do código. Elegantes e simples, esses são os benefícios do Pascal, por favor, cumpra-os!
Princípio: A simplicidade é linda!
4. Subjanela
Muitas pessoas operam diretamente os controles na subjanela ao chamar uma subjanela, como:
se SetAlarmParamDlg.ShowModal = MrOK então
começar
AlarmTimes := StrToInt(SetAlarmParamDlg.Edit1.Text);
AlarmArea := SetAlarmParamDlg.SpinEdit1.Value;
fim;
Ai meu Deus, se amanhã os usuários acharem que o Edit ou SpinEdit que você usa parece feio e substituí-lo por um controle bonito, o que você fará? Você não só precisa modificar o código da subjanela, mas também modificar o código do formulário principal. É claro que um programa com uma ou duas subjanelas não causará problemas. E se for um programa com mais de vinte subjanelas? Demorou um dia, mas o motivo foi só mudar um controle! Por que não tentar outro método? Se você usar atributos para representar os parâmetros que deseja usar, você salvará inúmeros códigos.
//formulário principal
se SetAlarmParamDlg.ShowModal = MrOK então
começar
AlarmTimes := SetAlarmParamDlg.AlarmTimes;
AlarmArea := SetAlarmParamDlg.AlarmArea;
fim;
//subformulário
interface
privado
FAlarmTimes : inteiro;
FAlarmArea : inteiro;
publicado
propriedade AlarmTimes: leitura de inteiro FAlarmTimes gravação FAlarmTimes;
propriedade AlarmArea: leitura de inteiro FAlarmArea gravação FAlarmArea;
implementação
...
FAlarmTimes := StrToInt(Edit1.Text);
FAlarmArea := SpinEdit1.Value;
Resultado Modal := SrOK;
...
Contanto que você persista dessa forma, você encontrará grandes benefícios. Uma subjanela só faz suas próprias coisas, e a interação entre a janela principal e ela é feita por meio de atributos. A subjanela não afetará a janela principal Não importa como a aparência da subjanela seja alterada, como os controles sejam substituídos ou como o código seja modificado, todo o programa permanece o mesmo, apenas a interface mudou.
Princípio: Modularize suas subjanelas As janelas também são classes. Como a comunicação entre as classes deve ser a forma como as janelas devem se comunicar.