Fórum Duvidas - Boas Patricas de POO #375533

edSant

Para mim programar usando OOP é usar conceitos de OOP. Não que o sistema inteiro tenha que estar desta maneira.

Eu mesmo não vi mta utilidade de se criar classe do tipo TCliente, TProduto...

Mas tento usar vários conceitos de OOP.

Por exemplo o que vc tem um form Padrão e faz herança para criar os outros cadastros... isso é conceito de OOP, vc ja está no caminho.

O que mais poderia fazer.. por exemplo criar metodos virtuais para validar o Salvar, por exemplo
function PodeSalvar:boolean;

Neste metodo vc faria um override; nas suas telas de cadastro e faria validações do tipo, tal valor tem q ser maior que zero. Todas as validações que tiver que fazer antes de salvar o registro faria neste metodo.

E deixaria ele assim no seu metodo salvar do form padrão
if not PodeSalvar then
exit;
cds.Post;
cds.ApplyUpdate(0);

Com isso vc estaria aplicando outro conceito de OOP.

Uma dica... sempre que vc tem que fazer o mesmo código ou bem parecido mais de uma vez... é um ótimo lugar para aplicar conceitos de OOP.

Opa Edsant,

POO é um grande paradiga, que inclui uma forma de pensar e abordar os problemas, conceitos e suas implementações em linguagens de programação, técnicas de desenvolvimento além de disciplinas como análise, projeto e testes.

Estar ´programando OO´ é algo relativamente vago... depende de como e em q contexto se interpreta isto. Dentro dos conceitos mais ´puristas´ vc não está nem perto -- até pq controles DataWare e técnicas RAD são geralmente ´anti-OO´ (no q diz respeito a boas práticas de implementação) -- entretanto são essas abordagens (DataWare e RAD) q tornam programar tão fácil para os iniciantes.

Na minha opnião particular, vc tem um longo caminho a percorrer, mas ele pode (e deve) ser percorrido um passo de cada vez. Cada pequenas e simples prática OO costumo ter grande impacto positivo -- então vc pode começar por elas (isso se vc já não está aplicando, não tenho como dizer)

1) ESTUDE, LEIA muito a respeito. Este tópico é muito amplo para ser discutido (ou aprendido) em um fórum.

Comece pelo básico. O poder do OO não está na herança apenas. Está principalmente no ENCAPSULAMENTO. Dividir responsabilidades entre classes especializadas! Comece por ai.

Outro grande aliado q vc deve ter sempre a mão é a COMPOSIÇÃO. Herança é muito bom, mas em muitas ocasiões a composição permite maior flexibilidade e um projeto mais simples e ´bonito´

2) Aplique conceitos básicos e simples como:

-- criar classes especializadas. classes para cuidar das configurações, do controle de acesso, etc.

-- um FORM deve apenas apresentar informação, ele não deve ser responsável por manter regras de negócio e principalmente não deve ter controles ligados ao banco de dados -- crie data modules para isso.

-- se livre das variáveis globais (como aquelas q são criadas com os forms, ex: var Form2: TForm2; -- com exceção da do Form principal, claro =)

-- etc

3) Assim q dominar os conceitos básicos (ou se já domina) então estude padrões de projeto e técnicas avançadas como OPF, MVP, MGM -- aqui são abordados de forma forte a criação de classes de negócio (como vc citou, TCliente, TProduto, etc) e da camada de negócios em sí. A criação de uma camada de persistência responsável por salvar/recuperar suas classes de negócio (persistentes) do banco de dados. A criação de uma camada de apresentação e a separação e comunicação entre essas camadas. UFA! :D

Vc pode não precisar disso tudo, mas é bom conhecer e, ao passo q vai conhecendo, aplicar o que achar interessante.


Eu particularmente não sou um purista... se houvesse uma escala OO eu diria q estou no meio. Atualmente não tenho necessidade em OPF e MVP -- posso dizer que conhecendo bem OO é possível aliar técnicas poderosas com a facilidade do RAD e controles DataWare -- pode não ser considerado uma boa prática OO mas serve para mim.

Ao passo q for conhecendo e implementando vc deverá encontrar que ponto serve para vc.

O importante não são as técnicas empregadas (em si) mas o resultado que elas devem proporcionar. Aplicar OO é ter aplicações com menos bugs, mais fáceis de testa e corrigir (menor custo de manutenção), mais fácil de adicionar novas funcionalidades ou alterar existentes.


Boa sorte.

T+

Outra coisa importante que deve colocar na sua cabeção como obrigatorio seria Padronizar tudo que for possivel, por exemplo: todos os edits, dbedits ou jvEdits... não importa para mim são ´Edits´ e na nomeclatura deles começam com ´ed´, dbgrids com ´dbg´, menuitem com ´mn´ com isso vc consegue aplicar rotinas mais genericas.


Por exemplo eu tenho um método que ao iniciar a Tela Principal eu atribuo a todos os menuItem o OnClick deles. Para eu não ter que ficar fazendo codigo em todos os Menu Item para abrir meus forms. Eu fiz com que no nome do Menu Item ficasse assim ´mn_´+´Nome da Class do meu form´. Dae a minha rotina pega o nome do Menu tira o ´mn_´ e pronto ele tem o nome da classe. Dae todas é so mandar abrir o form.

Imagina que eu não tenho codigo nenhum nos OnClick do meus Menu Item a unica coisa que tenho que fazer é criar um menu Item novo com a nomeclatura certa e pronto... o sistema ja sabe abrir ele.

Gostária de agradecer a resposta de todos..

osocram o q vc falou sobre os menu item. seria algo assim:

procedure TfrmPrincipal.FormShow(Sender: TObject);
var
i : integer;
begin
for i := 0 to ComponentCount -1 do
begin
if (Components[i] is TMenuItem) then
if (Components[i].Tag <> -1) then
(Components[i] as TMenuItem).OnClick := ChamarFormulario;
end;
end;

agora como implementar o ChamarFormulario ? rs..

Obrigado.

Olá a todos,

afarias, obrigado pela explicação..

eu assisti uma video aula do Leonardo C. Quartieri, onde ele mostra como usar POO na prática..

Nesse exemplo ele criou uma Classe Tconn onde ele criava uma conexão com o banco e outra classe TCliente onde ele também criou uma TQuery que trazia os dados...Até tudo bem..

A pergunta é o seguinte, como ele criou tudo em tempo de execução, ele simplemente não usou um DataModule.
Nos meus projetos, tenho datamodules lotados de Componentes de Conexão DBExpress...

Isso fez com q eu ficase horas pensando sobre o assunto...
Devo abolir o meu DataModule e criar as classes de conexão?

É nessa classe de conexão tb devo criar o Quarteto magico do DbExpress?

Sabe o que mata, e isso devo acontecer com outros programadores...
Você estar no meio de um projeto e achando que está ficando chick, ai vc descobre que tem outra maneira de fazer muito melhor e mais produtiva....Ai pensa em começar tudo de novo, ou continuar do jeito que tá? rs..

Mas beleza, um dia eu chego lá. força de vontade e leitura é que não falta..

Um abraço...

|Nesse exemplo ele criou uma Classe Tconn onde ele criava uma conexão
|com o banco e outra classe TCliente onde ele também criou uma TQuery
|que trazia os dados...Até tudo bem..

Tudo bem dependendo do ponto de vista. Num ponto de vista ´purista´ classes de negócio como TCliente não deveriam ter conhecimento do mecanismo de persistência (TQuery).

O q é entendido como boa prática seria ter uma classe TCliente q não tem a mínima noção de como recuperar ou salvar os dados (em banco de dados ou xml ou qualquer coisa) e outra classe, ex: TDadosCliente responsável pela persistência (com a Query ou qualquer outro mecanismo)

De qualquer forma, como disse no post anterior, não é bom ficar em 8 mas não precisa ir a 80. A solução apresentada já incorpora em algum grau o conceito de encapsulamento e especialização. O q já é um muito bom começo na minha opinião particular.



|A pergunta é o seguinte, como ele criou tudo em tempo de execução, ele simplemente não usou um DataModule.
|Nos meus projetos, tenho datamodules lotados de Componentes de Conexão DBExpress...

Quanto mais vc vai evoluindo na linguagem/ambiente/técnicas é comum que a situação vai se invertendo e vc passa a ver q códigos são mais práticos q colocar componentes e definir propriedades em tempo de projeto. Mas isso tb é uma questão particular -- devemos caminhar para o q nos é mais produtivo.

Não tenho nada contra DataModules com componentes Query entre outros. O q eu digo é apenas que mantenha esses DataModules o mais especializados possível. Tipo 1 para Cliente, 1 para Pedido, 1 para Produto, etc... (a ´granularidade´ fica a seu critério) -- mas nunca 1 (ou poucos) para tudo q tem no sistema.



|Isso fez com q eu ficase horas pensando sobre o assunto...
|Devo abolir o meu DataModule e criar as classes de conexão?

Vá amadurecendo a idéia aos poucos. Comece com DataModules especializados (como no vídeo q vc falou). Se estiver tão ansioso para ter classes de negócio separadas da persistência e tals, estude um OPF (o tiOPF por exemplo é muito bom) -- vc pode ver os exemplos e fazer pequenas aplicações.

Como tudo q se está aprendendo, e como implementar OO é mais difícil do q parece (ou querem q pensamos) vc deve, no início, produzir bem mais lento q o seu habitual. Faz parte da curva de aprendizagem.



|É nessa classe de conexão tb devo criar o Quarteto magico do DbExpress?

Como disse, o ´mais correto´ é ter a classe (1 geral *ou* 1 para cada BO) separada. Mas vc pode SIM usar tudo junto.



|Sabe o que mata, e isso devo acontecer com outros programadores...
|Você estar no meio de um projeto e achando que está ficando chick, ai vc descobre que tem outra maneira de fazer muito
|melhor e mais produtiva....Ai pensa em começar tudo de novo, ou continuar do jeito que tá? rs..

Cara não se preocupe com isso... Quando vc dominar OO estarão no seu ouvido dizendo q está tudo errado e existem um novo paradigma muito melhor no mercado e vc vai sentir a mesma coisa... rssss

Ser produtivo é muito relativo... programar OO geralmente toma mais tempo, principalmente até q vc domine e tenha um bom framework configurado. O grande ganho vem mesmo com a manutenção fácil, com o baixo número de bugs, etc.

Mas o q é realmente importante quando desenvolvemos um produto?? Seu cliente não vê como a coisa está por dentro. Vc pode fazer algo super dentro das técnicas OO mais lindas e q todos dizem ser ´o must´ e sua aplicação não valer nada pq nenhum cliente quer pq demorou muito pra ficar pronto ou não tem as funcionalidades q ele quer.

Preocupe-se em fazer bons programas do jeito q vc sabe. E preocupe-se em continuar aprendendo e melhorando (colocando esforço real nisto) ... A cada nova versão do seu programa vc aplica novas técnicas e melhora ele gradualmente.

Alpem disso, a coisa mais normal do mundo é olhar para um código q vc fez a 1 ano atrás e pensar: Q m***da eu tava fazendo!! Mesmo depois de anos vai continuar assim

=)



|Mas beleza, um dia eu chego lá. força de vontade e leitura é que não falta..

Isso, com certeza. Estuda, relaxa, e vai fazendo e melhorando! Estudo e prática é tudo! :D



T+