Aproveitando o meu post nesta thread do JavaFree.org, vou desenvolver aqui um pouco mais o relacionamento entre classes.
As decisões quanto a esse aspecto, podem levar a sua aplicação a ter um bom ou um mau design. Alguns conceitos, como os que abordam a questão da coesão, são decisivos para uma boa escolha para o relacionamento entre classes.
quarta-feira, 29 de julho de 2009
segunda-feira, 27 de julho de 2009
Como usar Scala no Eclipse
Neste artigo, mostrarei como usar o Eclipse como sua IDE para desenvolvimento em Scala.
Desde o meu post comentando o artigo do James Strachan, meu interesse na linguagem Scala só cresceu. Iniciei meus estudos, como todo bom aprendiz, com um editor de textos. Depois dos primeiros "Hello Words", resolvi buscar uma IDE e encontrei uma forma de usar o Eclipse para desenvolver com Scala. O processo é muito simples.
Requisitos recomendados:
Instalação: A IDE do Scala para Eclipse é melhor instalada (e atualizada) através do próprio Eclipse.
Terminada a instalação, você já será capaz de criar projetos Scala no Eclipse.
Veja abaixo um exemplo:
Links relacionados:
Tutorial em inglês: http://www.scala-lang.org/node/94
Site oficial: http://www.scala-lang.org/
Desde o meu post comentando o artigo do James Strachan, meu interesse na linguagem Scala só cresceu. Iniciei meus estudos, como todo bom aprendiz, com um editor de textos. Depois dos primeiros "Hello Words", resolvi buscar uma IDE e encontrei uma forma de usar o Eclipse para desenvolver com Scala. O processo é muito simples.
Requisitos recomendados:
- Java versão 1.6, update 14 ou superior (versão 5 no mínimo);
- Distribuição standard do Eclipse 3.5 ou superior.
Instalação: A IDE do Scala para Eclipse é melhor instalada (e atualizada) através do próprio Eclipse.
- Selecione Help -> Install new software
- Clique no botão Add Site...
- Entre com esta URL, http://www.scala-lang.org/scala-eclipse-plugin, na caixa Location
- Depois de clicar em OK, você deve ver "Scala Eclipse Plugin" como opção de instalação
- Clique no botão "Install..." e siga as instruções a partir daqui.
Terminada a instalação, você já será capaz de criar projetos Scala no Eclipse.Veja abaixo um exemplo:
Links relacionados:Tutorial em inglês: http://www.scala-lang.org/node/94
Site oficial: http://www.scala-lang.org/
sexta-feira, 17 de julho de 2009
Princípios de projeto - Parte VIII - Usabilidade
O blog Portal do Arquiteto publicou recentemente, uma série de cinco artigos que dizem respeito a problemas de usabilidade.
Segundo a Wikipedia:
E, no nosso contexto, nossos sistemas são as ferramentas. Assim, trazendo para o nossa área:
Nosso objetivo maior, quando estamos participando de um processo de desenvolvimento, é facilitar a vida do usuário. Precisamos que nosso sistema disponha de uma boa usabilidade, do ponto de vista do usuário, para que possamos cumprir esse objetivo.
O termo usabilidade se fundiu com o termo navegabilidade, mais ainda com o advento da WEB.
Seu usuário precisa sentir-se confortável durante os acessos ao seu sistema. Se o acesso aos pontos de interesse for dificultado, o sistema perde a credibilidade.
Quando estamos desenvolvendo sistemas específicos para uma empresa ou para um grupo de usuários que nos contratou, nossa busca pela excelência na usabilidade fica facilitada. Entretanto, quando nosso foco é geral, como uma loja online, por exemplo, o trabalho fica um pouco mais difícil. Nesses casos, a busca por uma boa usabilidade depende de uma eficiente pesquisa de opinião, pesquisa essa que o usuário nem sempre está disposto a responder.
Na maioria dos casos, se o usuário não se sente confortável em seu site, ele simplesmente o abandona e procura outro que o atenda perfeitamente em suas necessidades. Assim, essa pesquisa de opinião deve ser realizada, também, por pessoas de nosso conhecimento, capacitadas a testar nosso trabalho.
Em grandes empresas, normalmente, existe uma equipe de testes específica para tratar de casos como a usabilidade, baseando-se nos requisitos dos clientes.
Um princípio que aprendi nesses meus anos de experiência como desenvolvedor é: quem desenvolve não está apto a testar a usabilidade.
Por que?
Tenhamos sempre em mente a usabilidade, pois se um sistema é complicado de ser usado pelo usuário, para que existir sistema?
Parte I - Introdução
Parte II - Correção
Parte III - Design por contrato
Parte IV - Flexibilidade
Parte V - A Lei de Demeter
Parte VI - Eficiência
Parte VII - Coesão
Parte IX - Relacionamento entre classes
Segundo a Wikipedia:
Usabilidade é um termo usado para definir a facilidade com que as pessoas podem empregar uma ferramenta ou objeto a fim de realizar uma tarefa específica e importante.
E, no nosso contexto, nossos sistemas são as ferramentas. Assim, trazendo para o nossa área:
A usabilidade está diretamente ligada ao diálogo na interface e a capacidade do software em permitir que o usuário alcance suas metas de interação com o sistema. Ser de fácil aprendizagem, permitir uma utilização eficiente e apresentar poucos erros, são os aspectos fundamentais para a percepção da boa usabilidade por parte do usuário. Mas a usabilidade pode ainda estar relacionada com a facilidade de ser memorizada e ao nível de satisfação do usuário.
Nosso objetivo maior, quando estamos participando de um processo de desenvolvimento, é facilitar a vida do usuário. Precisamos que nosso sistema disponha de uma boa usabilidade, do ponto de vista do usuário, para que possamos cumprir esse objetivo.
O termo usabilidade se fundiu com o termo navegabilidade, mais ainda com o advento da WEB.
Seu usuário precisa sentir-se confortável durante os acessos ao seu sistema. Se o acesso aos pontos de interesse for dificultado, o sistema perde a credibilidade.
Quando estamos desenvolvendo sistemas específicos para uma empresa ou para um grupo de usuários que nos contratou, nossa busca pela excelência na usabilidade fica facilitada. Entretanto, quando nosso foco é geral, como uma loja online, por exemplo, o trabalho fica um pouco mais difícil. Nesses casos, a busca por uma boa usabilidade depende de uma eficiente pesquisa de opinião, pesquisa essa que o usuário nem sempre está disposto a responder.
Na maioria dos casos, se o usuário não se sente confortável em seu site, ele simplesmente o abandona e procura outro que o atenda perfeitamente em suas necessidades. Assim, essa pesquisa de opinião deve ser realizada, também, por pessoas de nosso conhecimento, capacitadas a testar nosso trabalho.
Em grandes empresas, normalmente, existe uma equipe de testes específica para tratar de casos como a usabilidade, baseando-se nos requisitos dos clientes.
Um princípio que aprendi nesses meus anos de experiência como desenvolvedor é: quem desenvolve não está apto a testar a usabilidade.
Por que?
- Em primeiro lugar, porque a equipe que desenvolveu o sistema, normalmente, conhece todos os caminhos (e atalhos) do sistema e está viciado em uma navegação que sempre funciona.
- Em segundo lugar, não desenvolvemos sistemas para nós e sim para o usuário/cliente. Então quem precisa avaliar se o sistema é utilizável de forma eficiente ou não é o usuário e não a equipe de desenvolvimento.
Tenhamos sempre em mente a usabilidade, pois se um sistema é complicado de ser usado pelo usuário, para que existir sistema?
Parte I - Introdução
Parte II - Correção
Parte III - Design por contrato
Parte IV - Flexibilidade
Parte V - A Lei de Demeter
Parte VI - Eficiência
Parte VII - Coesão
Parte IX - Relacionamento entre classes
quinta-feira, 9 de julho de 2009
Scala vai substituir o Java?
James Strachan, em seu blog, levanta essa questão interessante. Interessante, também, como a necessidade de substituir o Java tem tomado proporções incríveis na mente de algumas pessoas. Ruby, Scala, e muitas outras opções tem aparecido como alternativas mais simples ao Java.
E é justamente com a complexidade do Java que James começa o seu texto. James alega que a especificação do Java é muito complexa (600 páginas), falando de autoboxing, generics e diversas alternativas que Java oferece.
Eu, particularmente, no último Falando em Java, tive a oportunidade de ver o Fábio Kung desenvolvendo, "ao vivo", um programinha em Ruby para sortear números aleatórios. A lógica foi desenvolvida em uma linha (ou duas, pois a linha não coube na tela). Entretanto, para entender essa "única" linha, você precisaria entender diversos aspectos da linguagem. Ora, não é a mesma coisa que ocorre em Java? Não vejo vantagens em tudo ser escrito em apenas uma linha, só aumenta a complexidade para a leitura. E programadores Ruby o que diriam? É só se acostumar.
É óbvio que meu estudo sobre o Ruby está apenas no início, mas até o momento, ainda não vi esse "estouro de produtividade" prometida.
James continua seu texto falando sobre linguagens dinâmicas e dando a sua visão de porque o Scala substituiria o Java a longo prazo.
Acho interessante o estudo de diversas linguagens para que seu horizonte seja ampliado, para que o estudo de uma outra linguagem ajude o desenvolvedor a melhorar as suas práticas, para que você tenha mais opções no momento de atacar um problema.
Enfim, o que me tira do sério é o uso descabido da palavra replacement, como se uma outra linguagem fosse a tão falada bala de prata.
Como sempre digo aqui neste blog, bala de prata existe tanto quanto existem lobisomens.
E é justamente com a complexidade do Java que James começa o seu texto. James alega que a especificação do Java é muito complexa (600 páginas), falando de autoboxing, generics e diversas alternativas que Java oferece.
Eu, particularmente, no último Falando em Java, tive a oportunidade de ver o Fábio Kung desenvolvendo, "ao vivo", um programinha em Ruby para sortear números aleatórios. A lógica foi desenvolvida em uma linha (ou duas, pois a linha não coube na tela). Entretanto, para entender essa "única" linha, você precisaria entender diversos aspectos da linguagem. Ora, não é a mesma coisa que ocorre em Java? Não vejo vantagens em tudo ser escrito em apenas uma linha, só aumenta a complexidade para a leitura. E programadores Ruby o que diriam? É só se acostumar.
É óbvio que meu estudo sobre o Ruby está apenas no início, mas até o momento, ainda não vi esse "estouro de produtividade" prometida.
James continua seu texto falando sobre linguagens dinâmicas e dando a sua visão de porque o Scala substituiria o Java a longo prazo.
Acho interessante o estudo de diversas linguagens para que seu horizonte seja ampliado, para que o estudo de uma outra linguagem ajude o desenvolvedor a melhorar as suas práticas, para que você tenha mais opções no momento de atacar um problema.
Enfim, o que me tira do sério é o uso descabido da palavra replacement, como se uma outra linguagem fosse a tão falada bala de prata.
Como sempre digo aqui neste blog, bala de prata existe tanto quanto existem lobisomens.
Assinar:
Postagens (Atom)