''Nos dias de hoje é realmente difícil encontrar projetos que ainda usam
paradigmas de programação “arcaicos” como a programação estruturada. A
grande maioria das soluções são criadas a partir da programação
orientada a objetos (POO) ou outra abordagem mais atual. Em virtude
disso, os programadores tem acesso a toda uma estrutura de opções que os
permitem alcançar um novo patamar de excelência em suas aplicações.
Duas
das grandes forças da POO são os autos níveis de padronização e
produtividade que se pode alcançar. Iremos abordar um pouco sobre esses
tópicos na prática dentro da IDE do Delphi for Win32.
Comecemos pelo mais simples de se entender, a produtividade. Vamos imaginar o seguinte cenário:
Você
está iniciando um novo projeto no qual o único formulário onde o design
se distingue dos outros é o principal, enquanto os outros seguem um
padrão (fundo branco, botão de fechar, popup de opções e um painel no
centro).
Pode parecer exagero, mas por incrível que pareça, se
você for fazer todo esse preparo toda vez que criar um formulário,
perderá perder um tempo precioso, e no caso de um design mais complexo,
fazendo isso repetidamente, você corre o risco de posicionar os
componentes sem a exatidão desejada.
Para resolver esse problema,
usaremos a herança visual, isso nos permite criar um formulário que
serve de base para um herdeiro, ou seja, podemos desenhar um formulário e
logo depois criar outro exatamente igual! Para exemplificar esse
recurso, siga os passos seguintes:
-Crie uma nova aplicação VCL (biblioteca de componentes padrão do Delphi).
-No
formulário, crie um design que serviria de base para um sistema (a seu
critério). Depois de organizar seu formulário você está pronto para
herda-lo.
-Na barra de ferramentas acesse o menu File, New, Other.
-Na janela, selecione a opção “Inheritable Forms”. Desta forma o formulário que você criou estará disponível.
É
necessário levar alguns pontos em consideração. Um deles é que o
formulário herdado deve manter as características (atributos) do antigo,
ou seja, você poderá alterar as propriedades dos componentes que vierem
herdados, mas nunca apaga-los. O segundo é que não só os componentes
contidos são herdados, mas os eventos também, isso quer dizer que se
você criar um evento no formulário base, ele estará presente no herdeiro
através da palavra chave inherited. Veja um exemplo:
procedure TfrmTeste.FormCreate(Sender: TObject);
var cont:integer;
begin
showmessage('O formulário de teste está sendo criado!');
inherited;
end;
A
palavra inherited chama toda a códificação que está no evento do
formulário base, sendo que você pode criar rotinas antes ou depois dela.
No caso do exemplo, uma mensagem de aviso será exibida antes que a
codificão herdada seja executada.
Bom, até aqui demostrei uma
fração do poder da POO, aprofundando um pouco mais podemos obter um
nível ainda maior. Imagine a seguinte situação (clássica!):
Você
está desenvolvendo uma aplicação onde os componentes devem mudar de cor
quando receberem foco e voltar a cor original quando o perderem. Isso é
claro além de deixar todos os Tedits em UpperCase (caixa alta) para
interação com o banco de dados.
Certo, o que você faria?
Colocaria uma rotina em cada evento de cada componente? Se sua resposta é
sim você está parado no tempo! Veja as rotinas a seguir:
procedure TfrmBase.DesFocalizarComponentesBase(sender: TObject);
begin
(sender as TEdit).Color:=clWindow;
(sender as TEdit).Font.Color:=clBlack;
end;
procedure TfrmBase.FocalizarComponentesBase(sender: TObject);
begin
(sender as TEdit).Color:=clBlack;
(sender as TEdit).Font.Color:=clWindow;
end;
procedure TfrmBase.FormCreate(Sender: Tobject);
begin
for cont := 0 to self.ComponentCount - 1 do
begin
if(self.Components[cont] is TEdit)then
begin
(Components[cont] as TEdit).CharCase:=ecUpperCase;
(Components[cont] as TEdit).OnEnter:=FocalizarComponentesBase;
(Components[cont] as TEdit).OnExit:=DesFocalizarComponentesBase;
end;
end;
end;
Vamos
por partes...Primeiro vamos entender o que está acontecendo. Em teoria
foi criado um formulário e na codificação dele criamos duas funções:
FocalizarComponentesBase e DesFocalizarComponentesBase. Logo em seguida
foi criada uma rotina no evento OnCreate.
FocalizarComponentesBase
e DesFocalizarComponentesBase como os próprios nomes já dizem, recebem
um objeto como parametro, qualquer tipo de objeto, e na sua execução,
usa um cast para forçar o Delphi a enxerga-los como sendo do tipo Tedit,
e assim, altera as propriedades necessárias para o objetivo.
Ok!
Entendi, mas e agora? Muito simples! A chave de tudo esta no evento
OnCreate, pois nele é feito um loop que percorre todos os componentes do
formulário testando se cada um deles é do tipo Tedit, caso sejam,
recebem as funções criadas nos seus eventos OnEnter e OnExit.
Depois
de fazer isso tudo, todo o Tedit que estiver nesse formulário vai se
comportar da mesma forma como foi prevista no projeto, mas e daí? Criei
um formulário, e o resto? Resposta rápida: POO! Siga os passo mostrados
anteriormente no artigo para herdar esse formulário e vai notar que o
filho vai seguir o padrão do pai!
Imagine as possibilidades. É
possivel herdar todos os formulários de acordo com a sua necessidade,
simplesmente para obter um padrão de codificação e design sem precisar
perder um tempo valioso organizando tudo sempre que resolver acrescentar
algo ao seu sistema.
Existem muitas formas de se empregar isso,
tudo depende do que você está desenvolvendo e para qual objetivo.
Lembre-se sempre que a palavra inherited é quem chama a codificação do
formulário pai, use-a com sabedoria e tome cuidado para não sumir com
ela onde é necessária!
Créditos: Informatica Atualizada - Osmar = eu no Power - Pixel
paradigmas de programação “arcaicos” como a programação estruturada. A
grande maioria das soluções são criadas a partir da programação
orientada a objetos (POO) ou outra abordagem mais atual. Em virtude
disso, os programadores tem acesso a toda uma estrutura de opções que os
permitem alcançar um novo patamar de excelência em suas aplicações.
Duas
das grandes forças da POO são os autos níveis de padronização e
produtividade que se pode alcançar. Iremos abordar um pouco sobre esses
tópicos na prática dentro da IDE do Delphi for Win32.
Comecemos pelo mais simples de se entender, a produtividade. Vamos imaginar o seguinte cenário:
Você
está iniciando um novo projeto no qual o único formulário onde o design
se distingue dos outros é o principal, enquanto os outros seguem um
padrão (fundo branco, botão de fechar, popup de opções e um painel no
centro).
Pode parecer exagero, mas por incrível que pareça, se
você for fazer todo esse preparo toda vez que criar um formulário,
perderá perder um tempo precioso, e no caso de um design mais complexo,
fazendo isso repetidamente, você corre o risco de posicionar os
componentes sem a exatidão desejada.
Para resolver esse problema,
usaremos a herança visual, isso nos permite criar um formulário que
serve de base para um herdeiro, ou seja, podemos desenhar um formulário e
logo depois criar outro exatamente igual! Para exemplificar esse
recurso, siga os passos seguintes:
-Crie uma nova aplicação VCL (biblioteca de componentes padrão do Delphi).
-No
formulário, crie um design que serviria de base para um sistema (a seu
critério). Depois de organizar seu formulário você está pronto para
herda-lo.
-Na barra de ferramentas acesse o menu File, New, Other.
-Na janela, selecione a opção “Inheritable Forms”. Desta forma o formulário que você criou estará disponível.
É
necessário levar alguns pontos em consideração. Um deles é que o
formulário herdado deve manter as características (atributos) do antigo,
ou seja, você poderá alterar as propriedades dos componentes que vierem
herdados, mas nunca apaga-los. O segundo é que não só os componentes
contidos são herdados, mas os eventos também, isso quer dizer que se
você criar um evento no formulário base, ele estará presente no herdeiro
através da palavra chave inherited. Veja um exemplo:
procedure TfrmTeste.FormCreate(Sender: TObject);
var cont:integer;
begin
showmessage('O formulário de teste está sendo criado!');
inherited;
end;
A
palavra inherited chama toda a códificação que está no evento do
formulário base, sendo que você pode criar rotinas antes ou depois dela.
No caso do exemplo, uma mensagem de aviso será exibida antes que a
codificão herdada seja executada.
Bom, até aqui demostrei uma
fração do poder da POO, aprofundando um pouco mais podemos obter um
nível ainda maior. Imagine a seguinte situação (clássica!):
Você
está desenvolvendo uma aplicação onde os componentes devem mudar de cor
quando receberem foco e voltar a cor original quando o perderem. Isso é
claro além de deixar todos os Tedits em UpperCase (caixa alta) para
interação com o banco de dados.
Certo, o que você faria?
Colocaria uma rotina em cada evento de cada componente? Se sua resposta é
sim você está parado no tempo! Veja as rotinas a seguir:
procedure TfrmBase.DesFocalizarComponentesBase(sender: TObject);
begin
(sender as TEdit).Color:=clWindow;
(sender as TEdit).Font.Color:=clBlack;
end;
procedure TfrmBase.FocalizarComponentesBase(sender: TObject);
begin
(sender as TEdit).Color:=clBlack;
(sender as TEdit).Font.Color:=clWindow;
end;
procedure TfrmBase.FormCreate(Sender: Tobject);
begin
for cont := 0 to self.ComponentCount - 1 do
begin
if(self.Components[cont] is TEdit)then
begin
(Components[cont] as TEdit).CharCase:=ecUpperCase;
(Components[cont] as TEdit).OnEnter:=FocalizarComponentesBase;
(Components[cont] as TEdit).OnExit:=DesFocalizarComponentesBase;
end;
end;
end;
Vamos
por partes...Primeiro vamos entender o que está acontecendo. Em teoria
foi criado um formulário e na codificação dele criamos duas funções:
FocalizarComponentesBase e DesFocalizarComponentesBase. Logo em seguida
foi criada uma rotina no evento OnCreate.
FocalizarComponentesBase
e DesFocalizarComponentesBase como os próprios nomes já dizem, recebem
um objeto como parametro, qualquer tipo de objeto, e na sua execução,
usa um cast para forçar o Delphi a enxerga-los como sendo do tipo Tedit,
e assim, altera as propriedades necessárias para o objetivo.
Ok!
Entendi, mas e agora? Muito simples! A chave de tudo esta no evento
OnCreate, pois nele é feito um loop que percorre todos os componentes do
formulário testando se cada um deles é do tipo Tedit, caso sejam,
recebem as funções criadas nos seus eventos OnEnter e OnExit.
Depois
de fazer isso tudo, todo o Tedit que estiver nesse formulário vai se
comportar da mesma forma como foi prevista no projeto, mas e daí? Criei
um formulário, e o resto? Resposta rápida: POO! Siga os passo mostrados
anteriormente no artigo para herdar esse formulário e vai notar que o
filho vai seguir o padrão do pai!
Imagine as possibilidades. É
possivel herdar todos os formulários de acordo com a sua necessidade,
simplesmente para obter um padrão de codificação e design sem precisar
perder um tempo valioso organizando tudo sempre que resolver acrescentar
algo ao seu sistema.
Existem muitas formas de se empregar isso,
tudo depende do que você está desenvolvendo e para qual objetivo.
Lembre-se sempre que a palavra inherited é quem chama a codificação do
formulário pai, use-a com sabedoria e tome cuidado para não sumir com
ela onde é necessária!
Créditos: Informatica Atualizada - Osmar = eu no Power - Pixel
