Padrões de nomenclatura

Classes e interfaces - A primeira letra deve ser maiúscula e, se várias palavras forem escritas juntas para formar o nome, a primeira letra de cada palavra interna deve ser maiúscula (um formato chamado de "camelCase").
Para classes, os nomes devem normalmente ser substantivos(nome de "coisas"). Por exemplo: Dog//Cachorro
Para interfaces, os nomes devem normalmente ser adjetivos(características, qualidade), Por exemplo: Runnable // Executável

Métodos - A primeira letra deve ser minúscula, e depois as regras camelCase normais devem ser usadas. Além disso, os nomes devem normalmente ser pares de verbo-substantivo. Por exemplo: doCalculation // fazerCálculo

Variáveis - Como nos métodos, o formato camelCase deve ser usado, comecando com uma letra minúscula. É recomendado usar nomes curtos e significativos. Por exemplo:  buttonWidth // larguraDoBotao

Constantes - As constantes Java sào criadas marcando-se variáveis como static e final. Elas devem ser nomeadas usando-se letras maiúsculas como caracteres underscore como separadores. Por exemplo: MIN_HEIGHT // ALTURA_MINIMA

Exceções - Os nomes devem revelar a causa da exceção e devem terminar com o sufixo que representa a sua hierarquia de exceção: Exception ou Error. Por exemplo, em ArithemeticException sabemos que se trata de uma classe derivada de Exception, e não de Error, que foi causada por algum problema em uma operação aritmética.


Algumas classes com utilidade especifica têm formas especificas de serem nomeadas. A seguir são listados alguns modelos de nomenclatura para estes conjuntos de classes, baseados nas regras anteriores.

Entidades - O nome de uma entidade é uma exceção ao principio de Preferência de Domínio Técnico. Nomes de entidades não devem conter sufixo ou prefixos de nenhum tipo, nem mesmo o popular Entity. Nomes de entidades, são exatamente isso, nomes. Substantivos que são recolhidos do dominio do problema e que normalmente guiam o objetivo ou a operação do software.

Repositório - A nomenclatura do padrão Repository segue o modelo: [Entidade] Repository.
Esta nomenclatura segue o principio de Preferência de Dominio Técnico deixando o nome do padrão no fim do nome. O nome é precedido pelo nome da entidade a que este repositório se refere.

Serviço - O padrão Service tem duas peças: a interface do serviço e a implementação do serviço. A nomenclatura para a interface do padrão Service segue o modelo: [Proposito]Service. Esta nomenclatura segue o principio de Preferência de Dominio Tecnico deixando o nome do padrão no fim do nome. O nome é precedido pela descrição do proposito em forma resumida, por exemplo: EmailSendingService.
O nome da implementação do serviço segue o modelo: [Tecnologia][Proposito]Service, em que ao nome da interface do serviço é adicionado um prefixo que denota o tipo de tecnologia ou algoritmo que o serviço utiliza para satisfazer a interface, por exemplo: JavaMailEmailSendingService

DAO - O padrão DAO, semelhante ao padrão Service tem duas peças: a interface do serviço/estratégia e a implementação. Para classes de DAO associados a entidades, o nome da entidade é adicionado como prefixo para distinguir entre os contratos de cada entidade. O nome da interface segue o modelo [Entidade]DAO e o da implementação o modelo: [Tecnologia][Entidade]DAO. Esta nomenclatura segue o principio de Preferência de Dominio Técnico deixando o nome do padrão no fim do nome.
O nome da implementação começa com o nome da tecnologia de persistência que a implementação do DAO usa, seguindo pelo nome da interface que está sendo implementada, por exemplo JdbcCustomerDAO.

O que escrever no README.md do seu projeto no Github

Antes de sitar os tópicos, é boa pratica criar a descrição do seu projeto no README.md em inglês, pois as chances de pessoas de outros países verem seu projeto é grande, e não queremos que eles não entendam o que o nosso projeto faz, não é mesmo? Então sempre que possível escreva a descrição em inglês. 

Sinopse/Synopsis
Na parte superior do arquivo deve haver uma breve introdução e / ou visão geral que explica o que é o projeto. Esta descrição deve corresponder descrições adicionados para os gestores de pacotes (gemspec, package.json, etc.)

Exemplo de código/Code Example
Os desenvolvedores devem ser capazes de descobrir como seu projeto resolve o seu problema, olhando para o exemplo de código. Verifique se a API que você está mostrando é óbvio, e que o código é curto e conciso.

Motivação/Motivation
Uma breve descrição da motivação por trás da criação e manutenção do projeto. Isso deve explicar por que existe o projeto.

Instalação/Installation
Fornecer exemplos de código e explicações sobre como obter o projeto.

Referência API/API Reference
Dependendo do tamanho do projeto, se for pequena e simples o suficiente para os documentos de referência pode ser adicionado ao README. Para o tamanho médio a grandes projectos é importante, pelo menos, fornecer um link para onde os documentos de referência API viver.

Testes/Tests
Descrever e mostrar como executar os testes com exemplos de código.

Contribuintes/Contributors
Que as pessoas saibam como eles podem mergulhar no projeto, incluem links importantes para coisas como rastreadores de problemas, irc, contas de Twitter, se aplicáveis.

Licença/License
Um trecho curto descrevendo a licença (MIT, Apache, etc.)

O que são os Princípios SOLID?

Robert C. Martin, por volta dos anos 90, compilou cinco princípios da orientação a objetos que visam nos ajudar com a tarefa de obter um código mais sólido (S.O.L.I.D.). Já a criação do acrônimo S.O.L.I.D. propriamente dito, foi introduzida por Michael Feathers, igualmente integrante da Object Mentor Inc. e autor do livro Working Effectively with Legacy Code. Feathers, na busca por facilitar a absorção da ideia, percebeu que a junção das cinco letras iniciais dos princípios, a saber: Single Responsability Principle, Open Closed Principle, Liskov Substitution Principle, Interface Segregation Principle e Dependency Inversion Principle, formavam a palavra Solid, que nos remete aos objetivos implícitos dos princípios, isto é, um desenvolvimento mais sólido.

Os cinco princípios da OO:

• Single Responsibility Principle (SRP), ou, Princípio da Responsabilidade Única. Esse princípio diz que as classes devem ser coesas, ou seja, terem uma única responsabilidade. Classes assim tendem a ser mais reutilizáveis, mais simples, e propagam menos mudanças para o resto do sistema.
• Open Closed Principle (OCP), ou Princípio do Aberto Fechado. Diz que as classes devem poder ter seu comportamento facilmente estendidas quando necessário, por meio de herança, interface e composição. Ao mesmo tempo, não deve ser necessário abrir a própria classe para realizar pequenas mudanças. No fim, o princípio diz que devemos ter boas abstrações espalhadas pelo sistema.
• Liskov Substitution Principle (LSP), ou Príncipio da Substituição de Liskov. Esse princípio diz que precisamos ter cuidado para usar herança. Herança é um mecanismo poderoso, mas deve ser usado com parcimônia, evitando os casos de Gato-estende-Cachorro, apenas por possuírem algo em comum.
• Interface Segregation Principle (ISP), ou Princípio da Segregação de Interfaces. Esse princípio diz que nossos módulos devem ser enxutos, ou seja, devem ter poucos comportamentos. Interfaces que tem muitos comportamentos geralmente acabam se espalhando por todo o sistema, dificultando manutenção.
• Dependency Inversion Principle (DIP), ou Princípio da Inversão de Dependências. Esse princípio diz que devemos sempre depender de abstrações, afinal abstrações mudam menos e facilitam a mudança de comportamento e as futuras evoluções do código.

Regras de Declaração para Arquivos-Fonte Java

• Um arquivo de código-fonte só pode ter uma classe pública (ex.: public class Hello{…}).
• Se o arquivo de código-fonte tiver uma classe pública, seu nome terá que coincidir com o nome dessa classe.
• O arquivo só pode ter uma instrução package, porém, várias de import.
• A instrução de package (se houver) deve ficar na primeira linha (fora os comentários) do arquivo de código-fonte.
• A instrução import (se houver) deve vir depois de package e antes da declaração class.
• Se não houver instrução package, as instruções import terão que ser as primeiras (fora os comentários) do arquivo de código-fonte.
• As instruções package e import são aplicadas a todas as classes do arquivo.
• O arquivo pode ter mais de uma classe não pública.
• Os arquivos que não tiverem classes public não apresentarão restrições de nomeação, ou seja, podem ter um nome que não seja o mesmo de nenhuma das classes do arquivo.

O que é um DAO?

DAO significa Data Access Object. É uma estratégia de implementação que tem como objetivo separar a lógica de acesso a dados das regras de negócio de sua aplicação.
É um padrão para persistência de dados, por exemplo em uma aplicação que utilize a arquitetura MVC, todas as funcionalidades de bancos de dados, tais como obter as conexões, mapear objetos Java para tipos de dados SQL ou executar comandos SQL, devem ser feitas por classes DAO. A  ideia é escrever o código de acesso a dados em uma classe separada que implemente uma interface. Fazendo assim com que o resto do seu sistema tenha acesso direto apenas a esta interface.

Quais as vantagens?

A vantagem de usar objetos de acesso a dados é a separação simples e rigorosa entre duas partes importantes de uma aplicação que não devem e não podem conhecer quase que nada uma da outra, e que podem evoluir frequentemente e independentemente. Alterar a lógica de negócio pode esperar apenas a implementação de uma interface, enquanto que modificações na lógica de persistência não alteram a lógica de negocio, desde que a interface entre elas não seja modificada.

• Pode ser usada em uma vasta porcentagem de aplicações;
• Esconde todos os detalhes relativos a armazenamento de dados do resto da aplicação;
• Atua como um intermediário entre a aplicação e o banco de dados;
• Mitiga ou resolve problemas de comunicação entre a base de dados e a aplicação, evitando estados inconsistentes de dados.

Como mostrado no diagrama, a abordagem escolhida é isolada ao DAO, enquanto apenas os métodos de acesso a dados pertinentes estão expostos através da interface. Em  um projeto que implemente o DAO, é bastante fácil de trocar de uma implementação para outra com um impacto mínimo para a sua aplicação.

Melissa Lobo.