Diferença Entre Padrão de Projeto e Convenção

Faaaaaaaaaaaaaaaaaaaaaala minha galerinha! Bem, o motivo deste tema foi devido à uma conversa que tive com alguns amigos do trabalho. Nesta, ocorreu uma história na qual uma pessoa chegou até um deles e foi falar sobre Padrões de Projeto se referenciando ao seu código fonte, identação, comentários etc... Ops! não pera!

Isso mesmo, como puderam ver, as pessoas confundem as vezes sobre a diferença de duas coisas básicas: Padrão de Projeto e Convenção. Tendo em vista este contexto, vamos falar um pouco sobre os dois. Lets!

Regras e convenções de nomenclatura

Quando programamos em Java, devemos levar em consideração as convenções de nomenclatura para deixar nosso código o mais legível e documentável possível, pois um dos objetivos da programação orientada a objetos é o reaproveitamento do código.

É muito provável que quem não tenha experiência com programação sinta dificuldade de identificar todos os termos utilizados neste artigo, mas garantimos que tudo que será visto aqui será detalhado mais adiante, embora que este artigo se torna trivial a medida que programamos. 

Muitos compiladores como Eclipse e NetBeans dão um grande auxilio na hora de criarmos nosso projeto nos informando sobre as convenções de nomenclatura no momento que estamos criando os pacotes, classes, etc...

Nome de Classes

Por convenção, toda classe deve começar com uma letra maiúscula e, de preferência, não pode conter letras não ASCII (caracteres de língua de origem latina, como caracteres acentuados). Portanto, não é possível declarar uma classe com qualquer caracter especial (@, #, $, %, &, *, _, etc...) ou número.

Caso o nome de uma classe seja composto por mais de uma palavra, a primeira letra de cada palavra deve ser em maiúscula.

O nome da classe deve ser exatamente o mesmo nome de seu arquivo fonte ( .java ).

O nome da classe deve fazer referência total ao seu objeto (atributos e métodos contidos dentro da classe). Por exemplo: se tivermos uma classe com os atributos canal, volume e sintonia; e os métodos mudarCanal (), aumentarVolume () e diminuirVolume (); então, possivelmente chamaríamos esta classe de TV ou Televisao. Contudo, em uma classe que contivesse o atributo corDasPenas e o método voar () jamais chamaríamos de Pessoa (por que pessoas não tem penas e nem voam).

Exemplos de nomes de classes: Pessoa, ImpostoDeRenda, Conta, AgenciaDeEmprego, ...

Nome de Pacotes

Os pacotes devem começar com uma letra minúscula e podem usar letras não ASCII. Jamais poderemos iniciar o nome de um pacote com caracteres especiais (@, #, $, %, &, *, _, etc...) ou número.

Caso o nome de um pacote seja composto por mais de uma palavra, a primeira letra de cada palavra deve ser em maiúscula.

O nome do pacote deve ser o mesmo nome da pasta a qual ele se refere. Por exemplo, se os arquivos fonte estão na pasta criptografia, então o nome do pacote deve ser criptografia.

O nome do pacote deve fazer referência total às funções exercidas pelas classes dentro do pacote, pois pacotes servem basicamente para organizar os arquivos de código fonte de nosso projeto.

Exemplos de nomes de pacotes: criptografia, usuários, conexõesDeBancoDeDados , ...

Nome de atributos ou variáveis

Os atributos (variáveis) podem começar com qualquer letra e os caracteres $ ou _, porém não podem começar com números.

Caso o nome de um atributo (variável) seja composto por mais de uma palavra, a primeira letra de cada palavra deve ser em maiúscula.

Exemplos de nomes de atributos ou variáveis: x, y, resultado, valorDeX, valorDeY, ligado, ...

Nome de atributos finais ou constantes

Os atributos finais (constantes) devem ser escritos em letras maiúsculas.

Usamos underline (_) para separar nomes compostos de atributos finais (constantes).

Exemplos de nomes de atributos finais ou constantes: TAMANHO, PARAR_DE_EXECUTAR, ...

Bem, falamos um pouco dos tais patterns, agora vamos aos padrões.

Padrões de Projeto

Diariamente, inúmeros programadores em torno do mundo lidam com diversos problemas que “devem” ser resolvidos através de sua implementação em uma linguagem de programação. Na grande maioria das vezes essa mesma necessidade é exigida com demasiada rapidez e pouquíssimo prazo.

Para tanto, os profissionais desenvolvedores de linguagens que fazem uso do conceito de orientação a objetos criaram, a partir de tais necessidades, os Padrões de Projeto. Padrões de projeto são extremamente usados, questionados, reanalisados e exigidos por inúmeras empresas do ramo de Tecnologia da Informação (especialmente as que desenvolvem softwares - fábricas). O conceito é tão famoso que já foi usado para resolver problemas fora do ramo de TI, com estratégias de implementação atuante, uma vez que o modelo remete ao mundo real com exemplos de objetos agindo e sendo tais como no cotidiano do negócio envolvido.

Dentre tantos padrões existentes, alguns são muito famosos pela genialidade de sua criação enquanto outros deixam muitos usuários confusos quanto a como e onde usar e as suas diferenças em relação a outros padrões semelhantes. O DAO, por exemplo, é muito conhecido e usado no mundo de desenvolvimento de software em Orientação a Objetos, entretanto muitos confundem a real diferença entre este padrão e o padrão Repository.

Persistent Object - PO

Esse padrão é muito usado em conjunto com o framework de persistência ORM Hibernate. Representa apenas um objeto de persistência simples com atributos, métodos de recuperação e setagem, muito semelhante ao VO ou TO (Transfer Object), porém sem nenhuma referência a códigos de transação com o banco de dados.

Data Transfer Object - DTO

O próprio nome já diz muito: um objeto simples usado para transferir dados de um local a outro na aplicação, sem lógica de negócios em seus objetos e comumente associado à transferência de dados entre uma camada de visão (view layer) e outra de persistência dos dados (model layer). Muito frequentemente você verá esse padrão sendo usado em conjunto com um DAO. Veja na Figura 2 um exemplo claro dessa representação e desse conjunto entre os dois padrões.

Figura 2: Exemplo de união entre os padrões DTO e DAO

Esse padrão também é bastante usado quando não se deseja expor a camada de persistência, porém é preciso que sejam exibidos os mesmos dados na camada de apresentação. Por exemplo, considere uma tela de uma aplicação que necessite listar os dados de 10 pessoas cadastradas em uma tabela. Para acessar estes dados, a camada de persistência assim o faz com a listagem configurada em um ArrayList de 10 PO’s (vide padrão acima). Para passar esses valores à tela, a mesma lista antes tem de ser convertida para uma lista de DTO’s com mesmos atributos e métodos get’s/set’s. Tudo isso porque a mesma aplicação faz uso do JPA, por exemplo, ou Hibernate e os mesmos frameworks não permitem que os dados tidos como “lazy (preguiçosos)” perdurem até depois de a conexão ter sido fechada. Por tal razão a conversão se faz necessária e assim os dados poderão fazer o trajeto sem serem perdidos ou sem que nenhum erro de conexão venha a acontecer.

Observação: os padrões de projeto também não devem ser usados em detrimento do ambiente onde se está executando o mesmo projeto, a ideia é que eles sejam abstratos o suficiente para se adaptar, porém você será o autor principal disso, então não desconsidere o ambiente na hora de pensar em todos os cenários adaptáveis.

Plain Old Java Object - Pojo

Em setembro de 2000, Martin Fowler, Rebecca Parsons e Josh MacKenzie cunharam o novo termo para designar um objeto sem grande valor dentro do modelo de classes de um projeto, an ordinary Java Object. Na mesma ocasião os mesmos disseram:

“Nós nos perguntamos por que as pessoas eram tão contra o uso de objetos regulares em seus sistemas e concluímos que era porque faltava um nome fantasia para os objetos simples. Assim, demos-lhes um, e caiu muito bem.”

Resumindo, é um termo usado para denotar um objeto Java que não segue nenhum dos conceitos principais dos modelos de objetos Java, convenções e frameworks.

Os POJO’s conseguem, inclusive, ser convertidos em outros padrões já citados, como:

1. POJO Persistence -> PO
2. POJO Transmission Process -> DTO
3. POJO como presentation layer -> VO

Figura 3: Por mais simples que seja, são considerados objetos centrais e importantes em um projeto OO

Business Object - BO

Um objeto de negócios é um tipo de uma entidade inteligível sendo e agindo como um ator dentro da camada de negócio em uma arquitetura de n camadas orientado a objeto.

Basicamente sua função é encapsular a lógica de negócios para um objeto (que pode incluir vários POs e geralmente precisam de um BO em um PO). Um PO pode ser um BO no final das contas, mas antes precisa ser convertido para tal.

Há três conceitos principais sobre BO:

1. Contém apenas as propriedades do objeto de negócio;
2. Contém apenas os métodos de negócio;
3. Ambos.

Durante o uso efetivo, o conceito do que é correto não é importante, a chave é apropriada para a aplicação prática em suas próprias necessidades de projeto.

Value Object - VO

Esse padrão é um pouco confuso. Segundo a Wikipédia, um Objeto de valor “é um pequeno objeto que representa uma entidade simples, cuja igualdade não é baseada em identidade: ou seja, dois objetos de valor são iguais quando têm o mesmo valor, não necessariamente sendo o mesmo objeto”.

Isso parece confuso quando pensamos em objetos Java atuando como POJOs simples. Definições a parte, esse padrão até hoje sofre alterações em suas explicações. Alguns o definem de uma forma outros a sua maneira, etc. É um objeto usado basicamente para exibir dados na camada de apresentação.

Bem senhores, foi basicamente isso, espero que tenham gostado e não esqueçam: Padrão é Padrão e Convenção é Convenção.