Arquivos

Archive for the ‘Boas práticas’ Category

Boas práticas para Banco de Dados

Em geral, DBAs e Desenvolvedores não conhecem muito bem boas práticas para otimizarem seu ambiente/aplicação, muitas vezes isso decorre da falta de boa formação ou falta de experiência mesmo. Para ajudar com isso, a IBM dispões de um site muito interessante com uma coleção de boas práticas para DB2, porém boa parte pode ser aplicada para outros BDs. O site fala desde instalação até escrita de aplicações.

O link para o mesmo está aqui.

Aproveitando o post, a algum tempo eu criei um artigo com boas práticas em SQL para desenvolvedores que pode ser útil, aqui está o link.

Enjoy!

Validador de sites do W3C

Para quem quer validar se seu site está nos padrões estabelecidos pelo W3C, eis O link:

http://validator.w3.org/

Enjoy!

Slides sobre Desig Patterns

Criei um set de slides para me auxiliar na aula introdutória sobre design patterns (Padrões de Projeto).

Tenho um post introdutório aqui, que pode ser utilizado como texto e aqui estão os slides.

Enjoy!

Padrões de Projeto – Design Patterns

Atualmente o termo padrões de projeto, ou design patterns é cada vez mais falado entre desenvolvedores, analistas e arquitetos de TI. É esperado que profissionais Plenos ou Seniores conheçam muito bem os principais padrões e estejam aptos a aplicar os mesmos em seus projetos.

A idéia deste post é descrever basicamente o que são os tais padrões de projeto e citar os principais.

Basicamente padrões de projeto são soluções reutilizáveis para problemas comuns. Como assim? Vamos supor que você quer implementar um software que precisa se conectar ao banco de dados e retornar dados para o usuário, porém você não quer que o programador entre em contato com a regra de negócio, pois esta vai ser desenvolvida por um outro programador mais sênior, então você pode utilizar um padrão chamado Business Delegate, que basicamente fornece uma camada com a qual o programador júnior vai poder interagir.

Um termo muito falado sobre o tema é o tal de GOF, ou Gang of Four. Fala-se gangue dos 4 pois trata-se de uma coleção de 19 padrões de projeto documentados elaborados por 4 pessoas: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Existe um ótimo livro sobre o tema que inclusive eu recomendo: “Padrões de Projeto“, pode ser visto e comprado aqui.

Os padrões do GOF podem ser utilizados nas linguagens Orientadas a Objetos, não é algo específico para Java. Dentre os mais conhecidos, posso citar:

  • Abstract Factory: Fornece uma interface para se criar uma família de objetos que tem características em comum. Não especifica a classe concreta. Um exemplo seria um criador de documentos que pode criar um e-mail ou um pdf.
  • Adapter (or wrapper ): Como o nome diz, é um adaptador. Ele permite que classes que normalmente não poderiam interagir devido a interfaces incompatíveis, o façam. Este padrão prove uma interface que pode ser utilizada pela classe anteriormente incompatível.
  • Prototype: É um padrão de criação que baseia-se na criação de objetos através da clonagem de um protótipo, utilizando o método clone() ao invés do new(), dessa forma evitamos custos.
  • Facade: Fornece uma interface única e simplificada para uma série de interfaces em um sistema. Por exemplo, nós temos muito código para iniciar algum processo, envolvendo N classes e métodos, então, ao invés de replicar este mesmo código em todos os locais de nossa aplicação que utilizem este processo, podemos criar um facade que encapsula o processo e que recebe somente o que for necessário para o processo.
  • Singleton: Esta é o mais famoso e mais questionado em entrevistas. Basicamente seu objetivo é garantir que haverá somente uma instância do objeto em memória, não importando quantas vezes ele será chamado/construído.

Além do GOF, temos os padrões de projeto Enterprise, que como o nome diz, são indicados para aplicações enterprise, a listagem completa dos mesmos pode ser vista aqui . Um ótimo livro sobre o assunto pode ser visto aqui . Os padrões mais comuns são:

  • Business Delegate: É como uma camada que permite que os clientes (programas, classes, etc) não interajam diretamente com os serviços/classes de negócio. Com esta “camada” de bando de dados, nos reduzimos o acoplamento entre a camada de apresentação e os serviços de negócio, por exemplo, a camada de apresentação passa os parâmetros para a camada de negócio e assim “delega” o restante do processo a mesma, dessa forma, estamos escondendo a implementação do negócio das camadas superiores da aplicação.
  • Data Access Object (DAO): Esse é o mais comum! Um DAO abstrai e encapsula todo o acesso a uma fonte de dados. O DAO gerencia a conexão, obtêm e armazena dados!
  • DataSource (DS): É a representação da fonte de dados. Um DS pode ser um banco de dados, um arquivo XML, etc…
  • TransferObject (TO): É utilizado para transferir dados entre uma aplicação e algum componente tal como um EJB, é como um contêiner que transporta “coisas”. Normalmente, nós temos um DAO que utiliza um TO para retornar dados para um cliente, também normalmente criando um objeto do tipo VO (Value Object) com os dados do TO.

Certamente a breve descrição dos padrões enterprise não deve ter ajudado muito, pois os mesmos são mais complexos, para seu entendimento é necessário mais estudo e implementação do que uma breve leitura.

Finalmente, esta foi somente a ponta do iceberg! Que sirva como uma breva introdução. Espero ter colaborado com este breve artigo!

Enjoy!

TDD – Test Driven Development

Algo que tem sido muito falado atualmente são as metodologias de desenvolvimento ágil, e um dos pilares de tais metodologias é a TDD, traduzindo, Desenvolvimento Dirigido a Testes.

TDD (Test Driven Development) é um técnica de programação ágil que tem aspectos de especificação e validação.
Com TDD especificamos nosso software em detalhes no momento que vamos escrevê-lo criando testes executáveis e rodando-os de maneira que eles mesmos testem nosso software.

Trocando em miúdos, quando vamos escrever um software, nós começamos escrevendo seu teste, uma classe que vai testar o software, assim, testamos o software e vamos o remodelando até o momento no qual os testes não mais falharem, então concluímos que TDD pode ser definida como uma técnica de programação onde todo o código produzido é criado em resposta a um código que falhou.

Parece bem simples a princípio, mas não é. TDD tem muitas técnicas. Não é simplesmente uma forma de testar softwares, mas sim de desenhar as aplicações.

Como funciona?

Basicamente, escrevemos um teste, rodamos este teste até que algo falhe, escrevemos o código fonte mais simples possível para passar neste teste, escrevemos o teste (aprimorando-o para cobrir mais aspectos do código fonte do produto), testamos até que algo falhe, reescrevemos nosso código para que ele passe no teste…. e ficamos neste ciclo até nosso software estar completo!

Vale a pena conhecer mais o tema, sugestões são:

- Este ótimo post de Scot Ambler
Este vídeo

Enjoy!

Firefox Accessibility Extension

fevereiro 20, 2009 2 comentários

Achei um ótimo plugin para o Firefox que possibilita testarmos aplicações WEB quanto as normas do W3C (ou normas que você pode criar).

Basta você instalar e executar os testes que desejar! É animal. Vale lembrar que é uma ótima prática produzir páginas de acordo com as normas do W3c!

Download e manual em http://firefox.cita.uiuc.edu/

Enjoy!

Técnicas de programação defensiva V

Continuando com os posts sobre programação defensiva, vamos para a quinta técnica:

Nunca deixe ninguém utilizar o que eles não deveriam utilizar!

Essa é fácil também. Quando estivermos programando algo, temos que pensar em proteger nossas coisas, ou seja, cuidar para que atributos, variáveis, classes, métodos, etc, possam ser utilizados somente por quem estiver autorizado a utilizar.

Como assim???

Falando mais praticamente, devemos limitar o escopo de nossos elementos ao menor nível possível. Por exemplo, devemos declarar atributos públicos, somente se realmente necessário.

Mas por que?

É simples. Imagine que deixando um atributo público, outras “pessoas” vão poder alterar seu valor, o mesmo vale para classes, métodos, etc… Isso não é perigoso? Alguem não pode alterar algo indevidamente? O correto é que você, em suas classes, tenha os métodos de acesso e alteração para os atributos da mesma, são os famosos getters e setters! Você deve ter os métodos de acesso aos seus atributos que garantam a persistência dos mesmos, ainda que seja uma classe simples, é muito importante criar os mecanismos de acesso no lugar de manter os atributos públicos.

É importante dizer que você não deve sair criando getters e setters indiscriminadamente, vale a pena a leitura deste artigo: http://blog.caelum.com.br/2006/09/14/nao-aprender-oo-getters-e-setters/.

Finalmente, vale a pena dar uma estudadinha nos modificadores de acesso do Java para implementar esta técnica mais eficientemente. Recomendo lerem esta página: http://www.javacamp.org/javaI/modifier.html.

É isso, cuide de suas coisas hein?!

Enjoy!

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

Junte-se a 151 outros seguidores