Crie um agendador de tarefas OO – Parte 2 - Clube Delphi 117

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (1)  (0)

Este artigo fala de técnicas de refatoração. Ensina como identificar e corrigir problemas de engenharia no software. É claro que para corrigir estes problemas alguns princípios de orientação a objetos também são utilizados. Para atingir o objetivo você também vai ver como criar métodos abstratos e como sobrescrever métodos. Além de entender para que serve e qual a diferença entre as instruções abstract, virtual, dynamic e override.

Atenção: esse artigo tem um vídeo complementar. Clique e assista!

[links]Crie um agendador de tarefas OO – Parte 1
Crie um agendador de tarefas OO – Parte 3[/links][rotulo-curso/]

[lead]Do que trata o artigo

Este artigo fala de técnicas de refatoração. Ensina como identificar e corrigir problemas de engenharia no software. É claro que para corrigir estes problemas alguns princípios de orientação a objetos também são utilizados. Para atingir o objetivo você também vai ver como criar métodos abstratos e como sobrescrever métodos. Além de entender para que serve e qual a diferença entre as instruções abstract, virtual, dynamic e override.

Para que serve

Refatorar é o processo de mudar a estrutura interna do software sem alterar seu comportamento externo. Esta técnica evita que o software se desgaste durante a vida útil do mesmo. Com esta técnica você consegue melhorar seu software sem que os clientes se sintam perdidos em cada alteração que você fizer.

Em que situação o tema é útil

Este tema é muito útil para sistemas com código desorganizados, pois a refatoração vai ajudar a melhorar o entendimento do código além de evitar a inclusão de novos defeitos durante futuras modificações.

Resumo do DevMan

Esta segunda parte da série “Crie um agendador de tarefas OO” aborda conceitos diferentes da primeira parte. O artigo anterior apresentou os conceitos básicos da orientação a objetos sem se preocupar com a arquitetura que estava sendo criada – sem aplicar padrões de projetos. Já este segundo artigo começa a refatorar o código da primeira versão a fim de corrigir os problemas de engenharia existentes. [/lead]

Na parte 1 deste artigo a primeira versão do agendador ficou pronta, mas com uma série de problemas. Não estou falando de erros, pois a aplicação funcionava sem gerar erro algum. Estou falando de problemas estruturais – alguns chamariam de problemas administrativos. Embora o agendador esteja cumprindo com sua obrigação de executar tarefas em horários pré-programados, estruturalmente ele está em péssimas condições. Não é necessário observar muito para perceber os problemas de engenharia presentes no código. No próximo parágrafo você encontra uma breve descrição dos problemas que o código do sistema possui. Desta maneira, se você ainda não leu a primeira parte desta série poderá ler este artigo sem ficar perdido no assunto.

O maior problema da primeira versão é que toda a lógica do programa está dentro da classe TForm1, ou seja, dentro do Form1. Tudo está neste formulário: salvar tarefas, salvar agendamentos, monitorar os agendamentos, cálculo da próxima execução de uma tarefa, cálculo da próxima execução de um agendamento, cálculo para saber se está na hora de executar uma tarefa e até mesmo o método para executar as tarefas.

[nota]Nota do DevMan

Refatoração é o processo de modificar o sistema para melhorar a estrutura do código sem alterar seu comportamento externo. Sempre que um pedaço de código da sua aplicação estiver "cheirando mal", você deve aplicar uma das quase 100 técnicas de refatoração disponíveis no site Refactoring Home Page. Este site é mantido pelo próprio Martin Fowler que é o autor do livro Refactoring: Improving the Design of Existing Code - ISBN 0201485672 - um dos livros mais importantes sobre o assunto. O link do site está no final do artigo. [/nota]

[subtitulo] “Bad smells in code” [/subtitulo]

[nota]Nota: Se você tiver o código fonte da primeira versão, esse vai ajudar a entender os próximos parágrafos. Junto com os arquivos disponíveis para download está o código fonte da primeira versão do agendador. Caso você não tenha, poderá baixá-los. [/nota]

Quando eu disse que tudo estava dentro da classe TForm1, eu não estava exagerando. Repare nos itens que eu citei no último parágrafo da introdução: o que mais a primeira versão faz além do que foi citado lá? Não faz mais nada. Tudo que o agendador faz foi escrito dentro da classe TForm1. Embora existam mais duas classes além da TForm1 – TTarefa e TAgendador – nenhuma vantagem da orientação a objetos foi usada. A classe TForm1 está muito grande e cheia de desvios feitos através de testes (instruções IF). Qualquer alteração no programa resultará em uma modificação na classe TForm1 e como esta classe está cheia de responsabilidades interligadas, qualquer modificação feita nela significa que outra parte da aplicação pode começar a gerar erros por conta disto – por isto todas as funções da aplicação devem ser testadas novamente.

Estes são um dos motivos para criar um sistema cujas responsabilidades estão separadas em classes, porém, existem muitos outros. Imagino eu que, se você já leu até aqui é porque você conhece os problemas de uma codificação ruim e deve estar mais interessado em como fazer da maneira certa do que nas consequências de se fazer da maneira mais fácil. Por isto vou direto ao ponto. Veja o que é e como refatorar um código, usando como exemplo a classe TForm1 do agendador.

[subtitulo]Vantagens das classes com responsabilidade única[/subtitulo]

A classe TForm1 está cheia de responsabilidades e isto não é bom. Isto é tão ruim que até existe um princípio da orientação a objetos que trata especificamente disto, chama-se: Princípio da Responsabilidade Única. Para seguir este princípio é preciso identificar todas as responsabilidades de uma classe e separar estes objetivos em mais classes a qualquer custo. Sim, é mais fácil falar do que fazer. O princípio diz o que deve ser feito, porém, como é que se faz para identificar e separar as responsabilidades de uma classe? Antes de aprender como faz, veja as vantagens que isto vai trazer.

A primeira vantagem é que quando qualquer classe possui apenas uma responsabilidade, isto significa que ela também possui apenas uma única razão para mudar. Quando as classes do seu sistema possuem apenas uma única responsabilidade você consegue fazer alterações, adicionar ou remover novos comportamentos no sistema sem ficar preocupado se o resto do sistema vai ser influenciado, pois cada classe do sistema tem sua responsabilidade e sabe como realizá-la indiferentemente do que acontece com as demais classes. Em outras palavras é possível alterar o sistema sem precisar testar o sistema inteiro novamente: você vai precisar testar somente a parte que foi alterada ou adicionada.

"

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?