[Artigos]  Entendendo a premissa de POO - Baixo Acoplamento e Alta Coesão Publicado por rboaro : Terça, Janeiro 15, 2013 - 08:58 GMT-3 (774 leituras)  4 Comentários    Enviar para um amigo    Versão para impressão Programação Orientada a Objeto, muito falada e pouco entendida, apesar de parecer simples, para quem trabalha de forma procedural pensar de forma estruturada como propõe a POO não é tão simples. Mudar a forma de programar e principalmente a maneira de pensar, requer persistência e muita leitura sobre o tema até que o conceito passe a ser entendido. Quando falo entendido, estou me referindo a capacidade de abstrair uma situação e pensar nela em algoritmos usando POO. Sem precisar lembrar todos os conceitos e regras. Em um dos fórums que participo me deparei com um tópico que falava de programacão RAD, POO e outros conceito que foram comentados. Mas o que me chamou a atenção foi a forma como o colega Caique Rodrigues explicou a premissa Baixo Acoplamento e Alta Coesão, que ao meu ver é o ponto de partida para qualquer projeto que deseja ser orientado a objeto. Segue abaixo a sua explicação. O que muitas pessoas não entendem em ‘’POO’’ é “baixo Acoplamento / Alta coesão”. estes segundo meu ver são os alicerces para tudo que vem depois. Um FORM com o seguinte código : procedure TFormCliente.BtnInserirClick ( Sender : TObject ) ; begin sqlCliente.Text := ‘SELECT * FROM CLIENTES WHERE 1=0’ ; cdsCliente.Close ; cdsCliente.Open ; cdsCliente.Append ; cdsClienteTipoFisicoJuridico.asString := ‘F’ ; end ; demonstra que toda a ‘’lógica de negócios’’ ( neste exemplo apenas um CRUD ) esta intimamente ligada a interface do usuário, caracterizando: “ALTO ACOPLAMENTO/BAIXA COESÃO” : A regra de negócios esta intimamente ligada a interface com o usuário, não sendo possível distinguir entre GUI ( Graphical User Interface ) e as regras para manipulação de registros em uma tabela. Neste ponto também observamos que se existir mais de uma forma de chamar a insercão de um registro teriamos o mesmo código replicado diversas vezes em um pop-up ou toolButton sem reutiliziação do mesmo. Em um primeiro ‘’refactoring’’ poderiamos resolver o problema de duplicidade de códigos criando uma nova procedure responsável pela inserção de do registro : procedure TFormCliente.InserirRegistro ; begin sqlCliente.Text := ‘SELECT * FROM CLIENTES WHERE 1=0’ ; cdsCliente.Close ; cdsCliente.Open ; cdsCliente.Append ; cdsClienteTipoFisicoJuridico.asString := ‘F’ ; end ; procedure TFormCliente.BtnInserirClick ( Sender : TObject ) ; begin InserirRegistro ; end ; Neste ponto resolvemos a reutilização de código podendo ter diversos eventos os quais chamarão a rotina InserirRegistro e teremos apenas um local de manutenção. Mas isso não resolve o problema ‘’Acoplamento/Coesão’’ Acoplamento = uma classe deve se ligar a outra o mínimo possível. Coesão = uma classe deve fazer somente o que ela se propõe a fazer ( FORM = GUI, CRUD – Create, Read, Update, Delete = outra classe. ) Não vou entrar no mérito sobre as diversas camadas que podem ser desenvolvidas visando minimizar o acoplamento e aumentar a coesão ( DAO, ORM, MVC ). Em uma arquitetura Client/Server simples ( ou simplificando : Form/Banco ) podemos aplicar um conceito simples que é a separação da GUI das operações CRUD, criando um FORM e um DataModule. Pensando no 1o ‘’refactoring’’, temos algo como : Constructor TFormCliente.Create ( AOwner : TComponent ) ; begin inherited Create ( AOwner ) ; dtmClientes := TdtmClientes.Create ( self ) ; end ; procedure TFormCliente.InserirRegistro ; begin dtmClientes.sqlCliente.Text := ‘SELECT * FROM CLIENTES WHERE 1=0’ ; dtmClientes.cdsCliente.Close ; dtmClientes.cdsCliente.Open ; dtmClientes.cdsCliente.Append ; dtmClientes.cdsClienteTipoFisicoJuridico.asString := ‘F’ ; end ; procedure TFormCliente.BtnInserirClick ( Sender : TObject ) ; begin InserirRegistro ; end ; Percebemos que os objetos necessários ao CRUD estão em outra classe. Melhoramos muito nosso código. Mas o problema persiste, ‘’ACOPLAMENTO/COESÃO’’ A forma mais simples de se determinar ‘’ACOPLAMENTO/COESÃO’’ é quando um objeto necessita fazer diversas chamadas a outro objeto para obter o resultado esperado : procedure TFormCliente.InserirRegistro ; begin // 5 chamadas a um objeto para inserir um registro... algo esta errado ! ==>dtmClientes.sqlCliente.Text := ‘SELECT * FROM CLIENTES WHERE 1=0’ ; ==>dtmClientes.cdsCliente.Close ; ==>dtmClientes.cdsCliente.Open ; ==>dtmClientes.cdsCliente.Append ; ==>dtmClientes.cdsClienteTipoFisicoJuridico.asString := ‘F’ ; end ; como diminuir o acopalmento ? como melhorar a coesão ? Relembrando : Acoplamento = Cada classe deve ter ligações mínimas com outras classes. Coesão : Cada classe deve se propor a fazer apenas 1 coisa e delegar as outras a outras classes ( neste exemplo : Form = GUI, CRUD = Datamodule ). deixando o Datamodule coeso : procedure TdtmClientes.InserirRegistro ; begin // todas as chamadas aos objetos do Datamodule estão em 1o nível ( Law of Demeter ). sqlCliente.Text := ‘SELECT * FROM CLIENTES WHERE 1=0’ ; cdsCliente.Close ; cdsCliente.Open ; cdsCliente.Append ; cdsClienteTipoFisicoJuridico.asString := ‘F’ ; end ; deixando o Form menos acoplado e coeso com sua funcionalidade : procedure TFormCliente.InserirRegistro ; begin // para inserção de registros no form temos apenas um ponto de Acoplamento com a classe CRUD : dtmClientes.InserirRegistro ; end ; procedure TFormCliente.BtnInserirClick ( Sender : TObject ) ; begin // todos os gatilhos ( Button, Popup, Menu, Actions ) devem chamar InserirRegistros, manténdo o acoplamento // com o CRUD apenas nesta procedure e não a cada chamada. InserirRegistro ; end ; Observando a premissa ‘’Baixo Acoplamento/Alta coesão’’ e fazendo uso do ‘’Law of Demiter’’ temos uma programação ‘’realmente’’ oritentada a objetos onde cada ‘’camada’’ ( objeto ) é responsável unica e exclusivamente pelas funções delegadas a ele e possui um acoplamento mínimo ( pontos de ligação ) e manipulação direta de objetos em 1o nível ( o form não realiza um Append em um CDS que esta no DTM, mas sim um InsereRegistro que esta no DTM ). O Form neste caso ainda é acoplado ( dependente ) do DataModule mas o Form pode ser trocado por uma nova versão sem interferir no funcionamento do Datamodule. O Datamodule pode ser reutilizado por diversos forms ou mesmo por uma rotina de importação onde não exista a entrada de dados, apenas um progressBar indicando o andamento da operação ou ainda por uma classe sem uma GUI. Percebemos que utilizando alguns conceitos de POO podemos diminuir os pontos de manutenção do código e aumentar sua reutilização. Não quero entrar no mérito de DAO, ORM, MVC, Design Patterns e tantas outras siglas e padroes POO, mas demonstrar que programar assim : procedure TFormCliente.BtnInserirClick ( Sender : TObject ) ; begin sqlCliente.Text := ‘SELECT * FROM CLIENTES WHERE 1=0’ ; cdsCliente.Close ; cdsCliente.Open ; cdsCliente.Append ; cdsClienteTipoFisicoJuridico.asString := ‘F’ ; end ; é utilizar o ‘’lado’’ ‘’Orientado a Eventos’’ ( onde um evento resolve tudo ) e não necessáriamente ‘’Orientado a Objetos’’ ( onde cada objeto é responsável por fazer única e exclusivamente uma operação direta ). O Delphi é sim uma linguagem ‘’Orientada a Eventos’’ e ‘’Orientada a Objetos’’. Cada uma de suas facetas podem ser utilizadas de forma independente ou conjunta. Saber identificar ‘’Alto Acoplamento/Baixa Coesão’’ e ser capaz desenvolver com ‘’Baixo Acoplamento / Alta Coesão’’ é o primeiro passo para dizer que esta se utilizando POO em qualquer linguagem. Não é o uso de um Framework ORM que deixará seu código “mais ou menos POO” e sim conceitos básicos que facilitam a reutilização e manutenção do mesmo. Parabéns Caique Rodrigues pela brilhante explicação

Comentários

Ordem:  Os mais antigos primeiro Os mais recentes primeiro Melhores primeiro

Comentários pertencem aos seus respectivos autores. Não somos responsáveis pelo seus conteúdos.

por: rboaro (rboaro@gmail.com) : Jan 15, 2013 - 09:55 (Informações sobre o membro | Enviar uma mensagem) http://www.cybersistemas.com.br

Exatamente amigo, é muito comum misturarmos tudo, a grande maioria aprende a programar de forma procedural. Hoje isso não é mais usado principalmente em treinamentos Oficiais Embarcadero, mas e o legado? Não podemos simplesmente esquecer tudo e começar um sistema do zero. Normalmente temos sistemas imensos com milhares de linhas e re-escrever tudo é um trabalho árduo e muitas vezes impraticável. A única forma de mudar para POO é ser persistente e ler muito sobre o assunto.

[ Comentários não permitidos para usuários anônimos. Por gentileza, registre-se ou conecte-se ao sistema



por: Benedicto (bsassis@uol.com.br) : Jan 16, 2013 - 12:45 (Informações sobre o membro | Enviar uma mensagem) http://http://

O bom seria o autor dispor de exemplo forma procedural e exemplo modificado usando POO, p/ inciantes ter ideia melhor sobre o assunto. Achei otima a dica, mas não consigo aplicar. Obrigado.

[ Comentários não permitidos para usuários anônimos. Por gentileza, registre-se ou conecte-se ao sistema



por: rboaro (rboaro@gmail.com) : Jan 16, 2013 - 07:40 (Informações sobre o membro | Enviar uma mensagem) http://www.cybersistemas.com.br

Olá.. Estamos em contato com o autor para criarmos uma série de artigos sobre o tema, em breve teremos ótimas novidades. Abraço!

[ Comentários não permitidos para usuários anônimos. Por gentileza, registre-se ou conecte-se ao sistema

Copyright© 2001-2016 – Active Delphi – Todos os direitos reservados