Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da ClubeDelphi DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
dê seu feedback
post favorito
Padrão Strategy - Artigo Clube Delphi 126
Refatoração de código aplicando princípios de orientação a objetos que facilitam a implementação das soluções chamadas de padrões de projetos, implementado o padrão Strategy para definir grupos de classes com comportamentos diferentes que podem ser trocados em tempo de execução.
ClubeDelphi 126
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da ClubeDelphi 126
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da ClubeDelphi 126
Padrão Strategy
Encapsule responsabilidades criando grupos de classes especializadas
Quando se está criando um software, a tendência é torná-lo o mais reutilizável possível, ou seja, minimizar o trabalho necessário para fazer alterações ou implementar novas funções, mas existem muitos problemas que dificultam o trabalho do programador de tornar o software reutilizável. Um exemplo destes problemas é o acoplamento entre as classes do sistema, pois sem o conhecimento adequado o programador provavelmente fará um programa cujas classes estarão fortemente interligadas.
Alto acoplamento e baixa coesão são dois problemas que acontecem muito com sistemas mal projetados. Acoplamento é o nome que se dá para a ligação existente entre duas classes, mas não no sentido de relacionamento, mas sim, no que uma conhece da outra. Quando uma classe conhece demais sobre outra, esta torna-se dependente da outra e vice-versa. Assim, se essa outra sofre alteração, é muito provável que a primeira também tenha que se ajustar em relação à mudança sofrida. Portanto, um nível grande de acoplamento não é recomendado.
A coesão por sua vez pode ser traduzida como a objetividade que uma classe pode possuir. É muito comum, mas não ideal, encontrar classes que realizam várias operações, por exemplo: imprimir um relatório e exibir uma mensagem na tela. Uma baixa coesão pode causar problemas durante a manutenção do sistema, visto que uma classe que faz várias coisas ao ter seu código alterado pode implicar em falhas e outras funcionalidades.
Um padrão de projeto é uma solução para problemas como o citado anteriormente. Claro que se pode inventar uma solução própria, mas até que ponto vale a pena investir tempo para criar uma solução para um problema que já foi solucionado? Além do mais quando um padrão de projeto é implementado, um projeto não está sendo prejudicado, pois um padrão de projeto não é simplesmente uma solução, ele normalmente é a melhor solução, uma vez que estão embasados em princípios de programação orientada a objetos.
Nota do DevMan
Princípios SOLID - Essa sigla é um acrônimo para a palavra em inglês solid, que significa sólido, solidez. Cada letra representa um acrônimo de um princípio, ou seja, temos um acrônimo de um acrônimo onde: S de Single Responsability Principle (SRP), O de Open/Closed Principle (OCP), L de Liskov Substitution Principle (LSP), I de Interface Segregation Principle (ISP) e D de Dependency Inversion Principle (DIP). Esse conjunto é o resultado de estudos e experiências de vários desenvolvedores que foram coletados e organizados formando boas práticas básicas para um bom sistema orientado a objetos. Os princípios de modelagem de objetos são guias que levam a construir software flexível e estável. Evitando dependência excessiva entre as classes, duplicação de código e outros problemas mais.
Os princípios de orientação a objetos são como regras de um protocolo que devem ser seguidos para que se alcance um bom design de projeto – os princípios ensinam o que é bom e o que deve ser evitado em um projeto de software. Conhecer pelo menos alguns destes princípios já é um começo se o objetivo é dominar a técnica de programação orientada a objetos.
Um bom design de software
O bom design de um software possui três características reconhecidas:
Manutenção – É a facilidade com que um sistema pode ser alterado para aplicar novas regras de negócio exigidas, mas não só regras e sim também melhorar seu desempenho, corrigir falhas e outras solicitações mais. Aplicações que possuem um bom design exigem poucos recursos (tempo, esforço e até mesmo capital) para realizar sua devida manutenção.
Reusabilidade – Em um sistema adequado é possível que os seus componentes possam ser reutilizados por outros sem grandes dificuldades.
"
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVP
Encapsule responsabilidades criando grupos de classes especializadas
Quando se está criando um software, a tendência é torná-lo o mais reutilizável possível, ou seja, minimizar o trabalho necessário para fazer alterações ou implementar novas funções, mas existem muitos problemas que dificultam o trabalho do programador de tornar o software reutilizável. Um exemplo destes problemas é o acoplamento entre as classes do sistema, pois sem o conhecimento adequado o programador provavelmente fará um programa cujas classes estarão fortemente interligadas.
Alto acoplamento e baixa coesão são dois problemas que acontecem muito com sistemas mal projetados. Acoplamento é o nome que se dá para a ligação existente entre duas classes, mas não no sentido de relacionamento, mas sim, no que uma conhece da outra. Quando uma classe conhece demais sobre outra, esta torna-se dependente da outra e vice-versa. Assim, se essa outra sofre alteração, é muito provável que a primeira também tenha que se ajustar em relação à mudança sofrida. Portanto, um nível grande de acoplamento não é recomendado.
A coesão por sua vez pode ser traduzida como a objetividade que uma classe pode possuir. É muito comum, mas não ideal, encontrar classes que realizam várias operações, por exemplo: imprimir um relatório e exibir uma mensagem na tela. Uma baixa coesão pode causar problemas durante a manutenção do sistema, visto que uma classe que faz várias coisas ao ter seu código alterado pode implicar em falhas e outras funcionalidades.
Um padrão de projeto é uma solução para problemas como o citado anteriormente. Claro que se pode inventar uma solução própria, mas até que ponto vale a pena investir tempo para criar uma solução para um problema que já foi solucionado? Além do mais quando um padrão de projeto é implementado, um projeto não está sendo prejudicado, pois um padrão de projeto não é simplesmente uma solução, ele normalmente é a melhor solução, uma vez que estão embasados em princípios de programação orientada a objetos.
Nota do DevMan
Princípios SOLID - Essa sigla é um acrônimo para a palavra em inglês solid, que significa sólido, solidez. Cada letra representa um acrônimo de um princípio, ou seja, temos um acrônimo de um acrônimo onde: S de Single Responsability Principle (SRP), O de Open/Closed Principle (OCP), L de Liskov Substitution Principle (LSP), I de Interface Segregation Principle (ISP) e D de Dependency Inversion Principle (DIP). Esse conjunto é o resultado de estudos e experiências de vários desenvolvedores que foram coletados e organizados formando boas práticas básicas para um bom sistema orientado a objetos. Os princípios de modelagem de objetos são guias que levam a construir software flexível e estável. Evitando dependência excessiva entre as classes, duplicação de código e outros problemas mais.
Os princípios de orientação a objetos são como regras de um protocolo que devem ser seguidos para que se alcance um bom design de projeto – os princípios ensinam o que é bom e o que deve ser evitado em um projeto de software. Conhecer pelo menos alguns destes princípios já é um começo se o objetivo é dominar a técnica de programação orientada a objetos.
Um bom design de software
O bom design de um software possui três características reconhecidas:
Manutenção – É a facilidade com que um sistema pode ser alterado para aplicar novas regras de negócio exigidas, mas não só regras e sim também melhorar seu desempenho, corrigir falhas e outras solicitações mais. Aplicações que possuem um bom design exigem poucos recursos (tempo, esforço e até mesmo capital) para realizar sua devida manutenção.
Reusabilidade – Em um sistema adequado é possível que os seus componentes possam ser reutilizados por outros sem grandes dificuldades.
"
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da ClubeDelphi DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
7 COMENTÁRIOS
William De Carvalho Brazilino
Ótimo artigo, é disso que estamos precisando.
[há +1 ano] -
Responder
Enio Tavares Da Cruz Araújo
Na pagina 57, o parametro da classe TTranporteArquivoTexto.Enviar está correto?
[há +1 ano] -
Responder
Paulo Quicoli
Sim, está correto. Observe na listagem o código que realiza a gravação do texto foi omitido. Na verdade ele utiliza o parâmetro passado Email: TIdMessage para ler a mensagem.
10. Try
11. //código de gravação de texto no arquivo
12. finally
13. CloseFile(Arquivo);
14. end;
Observe que no artigo também é dito que:
" A nova classe receberá o caminho do arquivo, e quando o método Enviar for invocado, as informações do e-mail serão salvas no arquivo ao invés de serem enviadas para o servidor de e-mail. "
No artigo apenas não foi mostrado onde esse caminho é passado. Faça o download completo dos fontes e comprove.
Abraço
10. Try
11. //código de gravação de texto no arquivo
12. finally
13. CloseFile(Arquivo);
14. end;
Observe que no artigo também é dito que:
" A nova classe receberá o caminho do arquivo, e quando o método Enviar for invocado, as informações do e-mail serão salvas no arquivo ao invés de serem enviadas para o servidor de e-mail. "
No artigo apenas não foi mostrado onde esse caminho é passado. Faça o download completo dos fontes e comprove.
Abraço
[há +1 ano] -
Responder
Alexandre Martinez
Na página 60 fala-se sobre quando usar interfaces e quando usar classes abstratas. O artigo diz:
"Com base nisto, se for necessário criar um grupo de classe cujos métodos serão todos diferentes entre as subclasses, é melhor usar interface. Por outro lado se existir um grupo de classes onde um ou mais métodos se repetem entre as classes do grupo, pode-se usar a classe abstrata para fazer a implementação."
Destas afirmações consigo entender o seguinte: Pode-se usar interfaces em alguns casos, e pode-se usar classes abstratas em todos os casos. (Sei que fui curto e grosso, mas precisava ser objetivo);
Talvez eu não tenha compreendido o assunto em profundidade e não consigo ver quando usar um ou outro. Por outro lado, talvez seja isso mesmo que eu entendi. Mas, ainda assim, embora uma classe abstrata também obrigue as subclasses a implementar um ou mais de seus métodos como o fazem as interfaces, há casos em que o uso de interfaces seria mais indicado?
"Com base nisto, se for necessário criar um grupo de classe cujos métodos serão todos diferentes entre as subclasses, é melhor usar interface. Por outro lado se existir um grupo de classes onde um ou mais métodos se repetem entre as classes do grupo, pode-se usar a classe abstrata para fazer a implementação."
Destas afirmações consigo entender o seguinte: Pode-se usar interfaces em alguns casos, e pode-se usar classes abstratas em todos os casos. (Sei que fui curto e grosso, mas precisava ser objetivo);
Talvez eu não tenha compreendido o assunto em profundidade e não consigo ver quando usar um ou outro. Por outro lado, talvez seja isso mesmo que eu entendi. Mas, ainda assim, embora uma classe abstrata também obrigue as subclasses a implementar um ou mais de seus métodos como o fazem as interfaces, há casos em que o uso de interfaces seria mais indicado?
[há +1 mês] -
Responder
Paulo Quicoli
Você pode ler sobre o assunto com muito mais clareza no artigo "POO – Crie sistemas flexíveis, expansíveis e com baixo custo de manutenção" da CD 110.
O mesmo mostra as vantagens e desvantagens de uso das interfaces e herança usando um exemplo para mostrar os problemas que a herança pode trazer.
O mesmo mostra as vantagens e desvantagens de uso das interfaces e herança usando um exemplo para mostrar os problemas que a herança pode trazer.
[há +1 mês] -
Responder
Alexandre Martinez
Obrigado pela dica, Paulo. Aqui na Clube Delphi sempre falam em programar para interfaces. Agora fez sentido pra mim. O artigo da CD 110 foi muito esclarecedor.
Abraço
Abraço
[há +1 mês] -
Responder
Cleidson Barbosa Da Silva
Ótimo artigo Paulo, parabéns!!
[há +1 mês] -
Responder
Você está em:
canal Delphi
Publicidade
Rafael Stavarengo
Space do autor
Programador de sistemas a 8 anos, integrante da equipe editorial da revista Clube Delphi. Domínio em Java, PHP e UML. Sólido conhecimento em Design Patterns e metodologia ágeis. Graduado em Análise e Desenvolvimento de Sistemas pela UNIPAR.
Space do autor
0
0
