Facilitando a compreensão de sistemas
Olá pessoal...
Hoje estava preparando minha coluna e percebi a necessidade de comentar sobre a importância de um modelo na confecção de um projeto, se você tem uma boa noção de documentação certamente poderá pensar, “Ele vai perder algum tempo para falar de nomenclatura de classes e atributos?” Mas, existe algo a mais nesta idéia, falo de “semiótica” em modelos computacionais.
Geralmente ao escutarmos algo sobre um novo projeto, começamos a pensar em linhas de código, nos “ifs” e ”elses” que possivelmente encontraremos no sistema, esquecendo-nos dos modelos que cercam este projeto, digo sempre aos meus alunos:
“Sempre que a vida lhe apresentar um desafio, tenha certeza que junto dele está a solução”, nunca soube se essa frase está sendo entendida como espero, mas queria dizer que quando temos um problema, seja ele qual for, temos que estudar o problema, e não somente sair loucamente buscando uma solução.
Os problemas computacionais geralmente estão associados a modelos computacionais e, esses modelos, estão no problema em si e não nos livros, deixe-me explicar melhor, não deixe para ler o livro quando estiver buscando a solução do problema, tenha-o lido antes de o problema aparecer.
Existem dois fatores importantíssimos para uma boa programação O.O.:
- Disciplina de programação;
- Desenvolvimento de modelos;
As disciplinas de programação geralmente estão vinculadas às:
- Regras para nomenclaturas de classes, atributos e métodos;
- Comentários no programa;
- Estrutura do programa;
- etc.
O Desenvolvimento de modelos geralmente está vinculado a:
- Diagrama de Classe;
- Cronograma de projeto;
- Diagrama de instância;
- etc.
Na programação Java, as classes sempre devem ter todas as palavras que formam o seu nome iniciadas em letra maiúscula (ExemploNomeClasse). Já métodos e atributos devem ter a primeira minúscula e a segunda em diante maiúscula. (exemploAtributo, exemploMetodo()).
Isso que alguns “programadores” chamam de “besteiras da linguagem” associado com algo que chamamos de bom censo é o melhor caminho para iniciar a programação O.O.
Observe os dois desenhos abaixo.
A “estrutura” das figuras representam classes, quando vemos esse tipo de figuras sabemos que se trata de uma classe e na parte superior temos o nome da classe, a intermediária temos os atributos e abaixo os métodos.
Geralmente quando criamos os atributos damos um nome a ele para que possamos identificá-lo no programa, agora pense na primeira classe, o que identifica diaTrbMs? Na realidade podemos até perguntar: “Quem foi o infeliz que deu esse nome para o atributo?”
Quando pensar em documentar algo, pense que esse documento não é apenas seu, na sua cabeça diaTrbMs pode ter o maior sentido do mundo, mas, a mim e muito possivelmente ao resto do mundo, isso não faz sentido nenhum.
É certo que a tecnologia estruturada de desenvolvimento também pede esse bom senso, mas leia a linha abaixo.
Double salarioMensal = Calcula.salarioMensal();
Aqui é onde parte da mágica se mostra.
“Pensar em O.O. é pensar nos objetos como eles são, ou melhor, como nós queremos que eles sejam, e ao programar em O.O. sinto-me livre para criar...” essa é uma frase que escrevi quando estava falando sobre orientação ao objeto e, a classe acima assim como qualquer outra, mostra bem o que quero dizer com essa frase.
Quero que minha classe seja assim, quero chamar o método para calcular o salário desta forma, mas antes de Eu querer, o Modelo deve permitir, certamente se esse projeto pedisse algo de segurança, poderia questionar o fato do método salarioMensal() ser estático, (veja o static na frente do método no desenho da classe) pois métodos estáticos podem ser de fácil acesso, mas vamos falar disso futuramente, hoje ficamos apenas nos modelos computacionais.
Fiz um curso de matemática com o professor Ricieri e ele dizia: “... os modelos matemáticos que deram certo foram aqueles que, de certa forma, eram semióticos...” ou seja, para um modelo dá certo ele deve falar por si só, um bom modelo certamente não precisa de um manual, ele se explica “per-si”, é como uma maquete, ao olhar, certamente, você sabe o que é.
Isso mostra a necessidade de uma boa regra de nomenclatura de classes, atributos ou métodos, pois se esse modelo for bom, certamente os modelos serão mais inteligíveis.
Na próxima coluna desejo iniciar um pequeno projeto de software, vamos fazer algo mais prático e mais ambicioso.
