Talvez por isso Java tenha ganhado tanto destaque nas empresas... porque você tem que ser um programador muito ruim mesmo para conseguir bagunçar um programa em Java. A linguagem, as IDE's é tudo muito regrado, tem forma especificada para tudo, isso de certa forma é muito bom.
Existe então padrão para como codificar, como escrever um programa, se uma variável deve ser minúscula, maiúscula, se for palavra composta devo usar "OutraPavara" ou "outra_palavra"? Enfim, muitas questões que são subjetivas ao programador, em java não são.
Confesso que tinha rascunhado um artigo sobre isso, mas achei outros muito melhor elaborados do que meu planejamento, então não vou escrever nada e vou passar os links.
Se você ainda tem dúvida de como fazer, quais prática adotar, não deixe de ler, é um tempo que vale a pena gastar.
Convenções de codificação em Java
Convenções de codificação em Java - parte 2
Convenções de codificação em Java - parte 3
Convenções de codificação em Java - parte 4
Até mais.
terça-feira, 23 de junho de 2009
segunda-feira, 22 de junho de 2009
Tipos de dados em Java: int, Double e String
Olá novamente.
Neste texto veremos como fazer uma classe em Java (bem simples) e como manipular 3 tipos de dados, o int e o Double e String, esses dois últimos são classes. Lembre de identificar e seguir as normas, uma classe (declaração) sempre deve iniciar com letra maiúscula, sendo assim "int" é um tipo primitivo de dados, String e Double são classes.
Veja o código e comentamos depois.
Dentro do main, criamos um objeto do tipo "Sistema" (instanciamos a classe que é o nosso programa) e setamos dados aos atributos. No fim usamos os get's para exibir na tela o valor que tem em cada atributo.
Observações gerais sobre o código:
- Você deve fornecer os dados no formato que o método está esperando. No caso o Double espera um valor do tipo decimal ou inteiro. O System.out.println espera uma string, como os atributos idade e peso não são, com a conactenação (que só é possível com strings) convertemos os valores para serem exibidos pelo método.
Neste texto veremos como fazer uma classe em Java (bem simples) e como manipular 3 tipos de dados, o int e o Double e String, esses dois últimos são classes. Lembre de identificar e seguir as normas, uma classe (declaração) sempre deve iniciar com letra maiúscula, sendo assim "int" é um tipo primitivo de dados, String e Double são classes.
Veja o código e comentamos depois.
Logo no início declaramos nome, idade e peso, com seus respectivos tipos. Em seguida implementamos os métodos assessores (get's e set's) para os atributos.
public class Sistema {
private String nome;
private int idade;
private Double peso;
public void setNome(String nome) {
this.nome = nome;
}
public String getNome() {
return this.nome;
}
public void setIdade(Integer idade) {
this.idade = idade;
}
public int getIdade() {
return this.idade;
}
public void setPeso(Double peso) {
this.peso = peso;
}
public Double getPeso() {
return this.peso;
}
public static void main(String[] args) {
Sistema sistema = new Sistema();
sistema.setIdade(10);
sistema.setNome("Teste");
sistema.setPeso(3.14);
System.out.println(""+sistema.getIdade()+"\n");
System.out.println(""+sistema.getPeso()+"\n");
System.out.println(sistema.getNome());
}
}
Dentro do main, criamos um objeto do tipo "Sistema" (instanciamos a classe que é o nosso programa) e setamos dados aos atributos. No fim usamos os get's para exibir na tela o valor que tem em cada atributo.
Observações gerais sobre o código:
- Você deve fornecer os dados no formato que o método está esperando. No caso o Double espera um valor do tipo decimal ou inteiro. O System.out.println espera uma string, como os atributos idade e peso não são, com a conactenação (que só é possível com strings) convertemos os valores para serem exibidos pelo método.
terça-feira, 9 de junho de 2009
Antes de programar: Análise Orientada a Objetos
Vamos recordar como pensar na solução computacional de um problema pelo ponto de vista da orientação a objetos. Este texto não é específico para Java, vale para qualquer linguagem que lhe possibilite programar OO (orientado a objetos).
Linguagens de programação orientadas a objeto assim como C++ e Java nos forçam a desenvolver em outro paradigma. Mais que desenvolver, esse novo paradigma provoca também modificações na análise de um software, oferecendo as diversas "visões" do mesmo problema, cada visão busca identificar e de certa forma representar os artefatos do software a ser desenvolvido.
O que é um objeto?
Objeto é a unidade base desse paradigma de análise e programação. Um objeto é uma abstração da realidade de tal forma que lhes restem apenas as características que interessam no mundo computacional. Não necessariamente um objeto computacional tenha que ser um objeto real.
Ao definir um objeto (e chamamos isso de classe, pois descreve uma "categoria", "conjunto de objetos"), nos perguntamos o que ele tem, e o que ele faz (os atributos e os métodos).
Exemplos:
Conexão com o banco de dados
- (tem) usuário
- (tem) senha
- (tem) endereço do servidor de BD
- (tem) nome do banco de dados
- (faz) Conectar
- (faz) Desconectar
Aqui basicamente definimos o objeto "conexão", que não é um objeto do mundo real, mas existe no mundo computacional.
Livro
- (tem) Título
- (tem) Autor
- (tem) Editora
- (tem) Nro de páginas
- (faz) ???
O que um livro faz? Quais são as ações de um livro? Aqui chegamos a mais um ponto interessante. As características e ações (atributos e métodos) de UM MESMO OBJETO DO MUNDO REAL podem ser diferentes para problemas distintos. Cada análise usa apenas o que é necessário daquele objeto na resolução do problema. Sendo assim, para uma transportadora, pouco importa o título do livro, importa qual o seu peso e volume (volume de quantidade de espaço), características essas que são dispensáveis para o caso de uma biblioteca.
Conclusão 1: A representação de um objeto no mundo computacional é menos complexa do que no mundo real, pois no mundo computacional usa-se apenas o que convém para a resolução de um problema epecífico. Faz-se uma abstração.
Isso nos leva a segunda conclusão.
Conclusão 2: A análise orientada a objetos torna as coisas mais simples, porque cada objeto é uma entidade simples, tendo de forma organizada seus atributos e métodos.
Para finalizar esse tópico, um objeto é representado, documentado, descrito através de uma Classe. O objeto é uma instância de uma classe, é um exemplar dentre os vários objetos que são do tipo de uma determinada classe.
Qual o problema de programar ou analisar estruturado?
Na verdade não há problema que não possa ser contornado, programadores e analistas experientes que nunca pensaram "orientado a objetos" tem em geral soluções elegantes para seus sotwares. O que acontece é que cada um tem uma, e cada um gasta um bom tempo até chegar a melhor solução, e a minha solução pode não se aplicar a outra pessoa, outro problema computacional.
Orientação a objeto é um padrão de como fazer as coisas de modo que todos o façam daquela forma, objetivando nenhum retrabalho, total reaproveitamento de códigos e análises já feitas anteriormente e ainda que isso se aplique a uma ampla gama de problemas computacionais.
Quem programa/analisa estrutural, pensa em que funções o software como um todo deverá ter. Orientado a objetos, pensa-se que dados e que ações cada objeto deverá ter. Pensando assim, em fragmentos mais pequenos e menos complexos há menos risco de esquecer ou menosprezar algum detalhe que no futuro (em uma análise/programação) estruturada poderia aparecer apenas durante um estágio avançado do desenvolvimento e complicar o projeto todo.
Em geral costuma-se dizer que os dados possuem maior integridade quando tratados por um programa OO, porque cada objeto é responsável apenas por SEUS métodos e seus dados, podendo apenas o objeto fazer sua manipulação, e isso de forma especializada.
Quem programa procedural/estruturado programa errado?
Não, em geral programas pequenos e de baixa complexidade não precisam de muito trabalho de análise para que possam ser desenvolvidos. A regra do custo/benefício da POO e análise OO é conforme o "tamanho do problema", quanto maior o programa, maiores serão os benefícios de uma análise OO.
Porém é mais trabalhoso no processo inicial a análise OO em comparação da estruturada, e na estruturada, os resultados em forma de "programa executável" (quando é um problema pequeno) tendem a aparecer antes. Como tanto para analisar como para programar OO há muitas regras, demora mais até que a "burocracia" seja resolvida e possa-se programar efetivamente. Ressalto que esse trabalho adicional de análise é muito valho, uma análise mal feita é um projeto fracassado.
Ok, e como eu analiso um problema "pelo ponto de vista da orientação a objetos" ?
Se leu até aqui já deve ter notado. O primeiro passo é identificar quem seão os objetos do problema. Vamos a um exemplo que fica mais fácil. Queremos fazer um software que é um dicionário, então um dos objetos é "o dicionário", um outro objeto poderiam ser "as palavras". Temos dois objetos, agora temos que descobrir dos nossos objetos quais atributos nos interessam.
Objeto dicionário:
Nro de palavras
Idioma
Objeto palavra
TextoPalavra
TextoSignificado
O segundo passo é identificar que ações correspondem a cada objeto. No caso o objeto "dicionário" teria os métodos "abrir", "fechar" e "procurar palavra". temos aqui mais um tópico interessante, o dicionário "procura palavras" ou seja, as palavras tem uma "relação" com o objeto "dicionário.
Mapeando as relações entre as classes podemos montar um diagrama de classes, que é um dos principais artefatos da análise pelo padrão UML.
UML? Quer dizer que tem um padrão para produzir uma especificação de análise orientada a objetos?
Exato, UML é um padrão para criar documentos de análise de software OO.
UML (Unified Modeling Language), de acordo com Rumbaugh e Jacobson (2000), é uma linguagem para especificar, visualizar e construir os artefatos de sistemas de software. Ela é um sistema de notação (incluindo a semântica para suas notações) dirigida à modelagem de sistemas, usando conceitos orientados a objetos.
Nossa! Mas isso é complicado de mais. Não teria como resumir isso tudo "ao essencial" ?
Muita coisa é essencial, tem que ler muito e praticar, não teria como resumir não.
Justamente por ser muitas regras, precisar ter uma "base de conhecimento" pelo menos "meio boa" é que a maioria ainda prefere analisar e programar de forma estruturada (cada um cria seus padrões), e que os quem programa e analisa OO se destaca, se fosse "comum" não teria porque fazer um blog falando de Java, que é uma linguagem voltada para programação OO.
Ok, me de alguns links então ...
Pesquise no google sobre "orientação a objeto", "análise orientada a objetos"... vá seguindo as pistas.
É interessante ler também algum livro (ou apostila) sobre UML, seja UML 1 ou 2.
Vamos aos softwares:
Jude Comunnity - Um programa free para criar documentos UML de análise de software.
Umbrello - É o software usado pelo pessoal que faz análise do KDE. Na documentação do KDE tem o help completíssimo. Eu particularmente aprendi mais sobre OO lendo essa documentação do que em livros. É claro, o conjunto é quem compõe a obra, talvez sem os livros o que diz na documentação não faria sentido nenhum.
Em futuras postagens que envolvam algum documento UML, usarei o Umbrello por preferência própria.
É isso! Até mais ver.
Referências:
RUMBAUGH, James; JACOBSON, Ivar; BOOCH, Grady. UML : Guia do Usuário. Rio de Janeiro, Campus, 2000.
RITTER, Helton. PACHECO, Jonas R. Gestão Financeira para Propriedades Rurais na Perspectiva de Análise Orientada a Objetos. Relatório de Prática Profissional Direcionada III do curso Bacharelado do Sistemas de Informação. Três de Maio, SETREM: novembro de 2008.
Linguagens de programação orientadas a objeto assim como C++ e Java nos forçam a desenvolver em outro paradigma. Mais que desenvolver, esse novo paradigma provoca também modificações na análise de um software, oferecendo as diversas "visões" do mesmo problema, cada visão busca identificar e de certa forma representar os artefatos do software a ser desenvolvido.
O que é um objeto?
Objeto é a unidade base desse paradigma de análise e programação. Um objeto é uma abstração da realidade de tal forma que lhes restem apenas as características que interessam no mundo computacional. Não necessariamente um objeto computacional tenha que ser um objeto real.
Ao definir um objeto (e chamamos isso de classe, pois descreve uma "categoria", "conjunto de objetos"), nos perguntamos o que ele tem, e o que ele faz (os atributos e os métodos).
Exemplos:
Conexão com o banco de dados
- (tem) usuário
- (tem) senha
- (tem) endereço do servidor de BD
- (tem) nome do banco de dados
- (faz) Conectar
- (faz) Desconectar
Aqui basicamente definimos o objeto "conexão", que não é um objeto do mundo real, mas existe no mundo computacional.
Livro
- (tem) Título
- (tem) Autor
- (tem) Editora
- (tem) Nro de páginas
- (faz) ???
O que um livro faz? Quais são as ações de um livro? Aqui chegamos a mais um ponto interessante. As características e ações (atributos e métodos) de UM MESMO OBJETO DO MUNDO REAL podem ser diferentes para problemas distintos. Cada análise usa apenas o que é necessário daquele objeto na resolução do problema. Sendo assim, para uma transportadora, pouco importa o título do livro, importa qual o seu peso e volume (volume de quantidade de espaço), características essas que são dispensáveis para o caso de uma biblioteca.
Conclusão 1: A representação de um objeto no mundo computacional é menos complexa do que no mundo real, pois no mundo computacional usa-se apenas o que convém para a resolução de um problema epecífico. Faz-se uma abstração.
Isso nos leva a segunda conclusão.
Conclusão 2: A análise orientada a objetos torna as coisas mais simples, porque cada objeto é uma entidade simples, tendo de forma organizada seus atributos e métodos.
Para finalizar esse tópico, um objeto é representado, documentado, descrito através de uma Classe. O objeto é uma instância de uma classe, é um exemplar dentre os vários objetos que são do tipo de uma determinada classe.
Qual o problema de programar ou analisar estruturado?
Na verdade não há problema que não possa ser contornado, programadores e analistas experientes que nunca pensaram "orientado a objetos" tem em geral soluções elegantes para seus sotwares. O que acontece é que cada um tem uma, e cada um gasta um bom tempo até chegar a melhor solução, e a minha solução pode não se aplicar a outra pessoa, outro problema computacional.
Orientação a objeto é um padrão de como fazer as coisas de modo que todos o façam daquela forma, objetivando nenhum retrabalho, total reaproveitamento de códigos e análises já feitas anteriormente e ainda que isso se aplique a uma ampla gama de problemas computacionais.
Quem programa/analisa estrutural, pensa em que funções o software como um todo deverá ter. Orientado a objetos, pensa-se que dados e que ações cada objeto deverá ter. Pensando assim, em fragmentos mais pequenos e menos complexos há menos risco de esquecer ou menosprezar algum detalhe que no futuro (em uma análise/programação) estruturada poderia aparecer apenas durante um estágio avançado do desenvolvimento e complicar o projeto todo.
Em geral costuma-se dizer que os dados possuem maior integridade quando tratados por um programa OO, porque cada objeto é responsável apenas por SEUS métodos e seus dados, podendo apenas o objeto fazer sua manipulação, e isso de forma especializada.
Quem programa procedural/estruturado programa errado?
Não, em geral programas pequenos e de baixa complexidade não precisam de muito trabalho de análise para que possam ser desenvolvidos. A regra do custo/benefício da POO e análise OO é conforme o "tamanho do problema", quanto maior o programa, maiores serão os benefícios de uma análise OO.
Porém é mais trabalhoso no processo inicial a análise OO em comparação da estruturada, e na estruturada, os resultados em forma de "programa executável" (quando é um problema pequeno) tendem a aparecer antes. Como tanto para analisar como para programar OO há muitas regras, demora mais até que a "burocracia" seja resolvida e possa-se programar efetivamente. Ressalto que esse trabalho adicional de análise é muito valho, uma análise mal feita é um projeto fracassado.
Ok, e como eu analiso um problema "pelo ponto de vista da orientação a objetos" ?
Se leu até aqui já deve ter notado. O primeiro passo é identificar quem seão os objetos do problema. Vamos a um exemplo que fica mais fácil. Queremos fazer um software que é um dicionário, então um dos objetos é "o dicionário", um outro objeto poderiam ser "as palavras". Temos dois objetos, agora temos que descobrir dos nossos objetos quais atributos nos interessam.
Objeto dicionário:
Nro de palavras
Idioma
Objeto palavra
TextoPalavra
TextoSignificado
O segundo passo é identificar que ações correspondem a cada objeto. No caso o objeto "dicionário" teria os métodos "abrir", "fechar" e "procurar palavra". temos aqui mais um tópico interessante, o dicionário "procura palavras" ou seja, as palavras tem uma "relação" com o objeto "dicionário.
Mapeando as relações entre as classes podemos montar um diagrama de classes, que é um dos principais artefatos da análise pelo padrão UML.
UML? Quer dizer que tem um padrão para produzir uma especificação de análise orientada a objetos?
Exato, UML é um padrão para criar documentos de análise de software OO.
UML (Unified Modeling Language), de acordo com Rumbaugh e Jacobson (2000), é uma linguagem para especificar, visualizar e construir os artefatos de sistemas de software. Ela é um sistema de notação (incluindo a semântica para suas notações) dirigida à modelagem de sistemas, usando conceitos orientados a objetos.
Nossa! Mas isso é complicado de mais. Não teria como resumir isso tudo "ao essencial" ?
Muita coisa é essencial, tem que ler muito e praticar, não teria como resumir não.
Justamente por ser muitas regras, precisar ter uma "base de conhecimento" pelo menos "meio boa" é que a maioria ainda prefere analisar e programar de forma estruturada (cada um cria seus padrões), e que os quem programa e analisa OO se destaca, se fosse "comum" não teria porque fazer um blog falando de Java, que é uma linguagem voltada para programação OO.
Ok, me de alguns links então ...
Pesquise no google sobre "orientação a objeto", "análise orientada a objetos"... vá seguindo as pistas.
É interessante ler também algum livro (ou apostila) sobre UML, seja UML 1 ou 2.
Vamos aos softwares:
Jude Comunnity - Um programa free para criar documentos UML de análise de software.
Umbrello - É o software usado pelo pessoal que faz análise do KDE. Na documentação do KDE tem o help completíssimo. Eu particularmente aprendi mais sobre OO lendo essa documentação do que em livros. É claro, o conjunto é quem compõe a obra, talvez sem os livros o que diz na documentação não faria sentido nenhum.
Em futuras postagens que envolvam algum documento UML, usarei o Umbrello por preferência própria.
É isso! Até mais ver.
Referências:
RUMBAUGH, James; JACOBSON, Ivar; BOOCH, Grady. UML : Guia do Usuário. Rio de Janeiro, Campus, 2000.
RITTER, Helton. PACHECO, Jonas R. Gestão Financeira para Propriedades Rurais na Perspectiva de Análise Orientada a Objetos. Relatório de Prática Profissional Direcionada III do curso Bacharelado do Sistemas de Informação. Três de Maio, SETREM: novembro de 2008.
Rodada 01: Where is the bug?
Olá pessoal! queremos que os Javaneses que leem esse blog participem! Por isso criamos os posts "where is the bug" onde serão cometidos todos os tipos de atrocidades programando em java.
A gente posta um código ou alguma coisa COM ERRO(S) e vocês respondem nos comentáios tentando solucionar. Quem responder mais coisas certas nos comentários GANHA fama de ser "o bom (ou a boa)" do "where is the bug?" aqui do blog.
Se ninguém postar solução, a solução oficial encontrada aqui pela equipe é postada duas semanas após lançado o desafio. O post do blog com o problema é atualizado, contendo aí a solução.
Entendidas as regras do jogo?
Well... play now!
O primeiro problema é um código de "Hello World" (para ver que até nisso da para errar). Segue o código na figura abaixo:
O código está no arquivo "teste.java" e não compila!
O que devo fazer?
--> SOLUCIONADO por Dalvan: veja nos comentários.
A gente posta um código ou alguma coisa COM ERRO(S) e vocês respondem nos comentáios tentando solucionar. Quem responder mais coisas certas nos comentários GANHA fama de ser "o bom (ou a boa)" do "where is the bug?" aqui do blog.
Se ninguém postar solução, a solução oficial encontrada aqui pela equipe é postada duas semanas após lançado o desafio. O post do blog com o problema é atualizado, contendo aí a solução.
Entendidas as regras do jogo?
Well... play now!
O primeiro problema é um código de "Hello World" (para ver que até nisso da para errar). Segue o código na figura abaixo:
O código está no arquivo "teste.java" e não compila!
O que devo fazer?
--> SOLUCIONADO por Dalvan: veja nos comentários.
Assinar:
Postagens (Atom)