O BIS utiliza alguns padrões de escrita do código para facilitar o desenvolvimento em equipe. Algumas são recomendadas pelo própria comunidade Java, outras foram criadas para o projeto. Algumas das vantagens desse método são:
- fácil manutenção de código fonte escrita por outro desenvolvedor ou pelo mesmo, já que com o passar do tempo todo desenvolvedor acaba alterando seu estilo de código.
- evita erros de interpretação com os nomes dos métodos, chamando um método que se "achava" que faria uma coisa devido ao seu nome enquanto acaba fazendo outra.
- facilita a verificação dos métodos já existentes. Em um sistema muito extenso e feito ao longo de anos e por mais de um desenvolvedor, é comum que não se conheça ou não se lembre dos métodos e funções já existentes. Nomes fora de padrão permitiriam que métodos possam ser duplicados, ou seja, mesma função em métodos distintos. Atrapalhando a manutenção que teria de ser realizada em diversos pontos, o que permitiria deixar algum "esquecido" e tendo um funcionamento errado.
Para o Java existe uma convenção de linguagem oficial ([Conventions for the Java TM Programming Language]), o BISCore recomenda sua leitura e que suas convenções sejam seguidas. Escrever o código como o "mundo" já o faz, facilitará inclusive a ao ler códigos de outros desenvolvedores que já seguem o padrão.
|
| Formatação de Código Fonte
|
| A formação do código fonte pode ser configurada em muitas IDEs. O BISCore já disponibiliza essas configurações em um arquivo para ser carregado no Eclipse. Como configura-lo pode ser encontrado no tópico de Configuração do Ambiente de Desenvolvimento.
|
|
|
| SVN e Formatação de Código
|
| A utilização de uma formatação do código diferente entre os desenvolvedores poderá fazer com que o SVN não interprete corretamente as diferenças das alterações, fazendo com que qualquer commit seja uma alteração de arquivo completo. Isso impede o rastreamento de alterações de cada usuário e causa um uso desnecessário de espaço no servidor SVN.
|
|
Convenções de Nome do BIS
Adicionalmente o BIS tem suas próprias convenções, as convenções previstas no BIS são mais específicas para o propósito do framework e não conflitem com as definidas pelo próprio Java.
Nomes dos Objetos
Sufixos de Objetos Gerais da Aplicação
- VO: O sufixo VO é dado aos objetos que representam um determinado objeto/informação. Por exemplo, um objeto que carregue os dados de um contato (como nome, endereço, telefone, RG, etc.) se for batizado de Contact, deve levar o prefixo VO, deixando o nome do objeto como ContactVO.
- Facade: O sufixo Facade é dado para as classes de Fachada dos módulos. Essas fachadas são usadas para permitir a comunicação de outras camadas com o core do módulo. Normalmente é recomendada apenas uma única fachada por módulo. Mas não é uma regra. Dependendo do módulo o desenvolvedor pode desejar ou precisar ter mais de uma fachada. Lembre-se apenas que quando mais fachadas tiver, mais lookups outros módulos tem de fazer para conseguir chamar diferentes métodos.
- CorePlugin: Sufixo usado nas classes que implementam um CorePlugin. Esta classe é utilizada para que o BISCore possa interpretar e se comunicar com o módulo.
- PluginDefinitions: Quando centralizamos as definições do módulo em uma classe separada da classe que implementa as interfaces/adapters que definem o plugin (core, presentation ou integration) damos esse sufixo para facilitar encontra-la quando precisamos atualizar suas definições, como por exemplo a versão.
Sufixos da Camada de Persistência
- MO: O sufixo MO é dado aos objetos do tipo Match Object. Estes objetos são utilizados pela camada de persistência para encontra VOs que foram persistidos. Por exemplo, um objeto usado para encontrar um ou mais contatos, se o VO foi batizado de ContactVO, seu MO deve ser batizado de ContactMO.
- DAO: O sufixo DAO representa Data Access Object e é dado aos objetos que fazem a persistência dos objetos. No padrão do BISCore, DAO é sempre uma interface que encapsula os verdadeiros DAOs através do pattern de Factory. Por exemplo: a interface que define a implementação do DAO para o objeto ContactVO deve ser batizada de ContactDAO. Para maiores informações sobre esse objeto leia no tópico da Persistência.
- EJB3DAO: Este sufixo é dado aos objetos que implementam o DAO e que utilizam o sistema de EJB3 + Hibernate oferecido pelo BISCore. Por exemplo: a implementação de EJB3, que implemente a interface ContactDAO deve ser batizada de ContactEJB3DAO. Para maiores informações sobre esse objeto leia no tópico da Persistência.
- DAOFactory: O sufixo DAOFactory é dado para as classes de Factory de DAOs dos módulos. É recomendado que só se tenha um Factory por módulo, embora não seja obrigatório, por isso recomenda-se que as classes devem ter o nome do módulo no começo. Por exemplo, para o objeto ContactVO, se ele faz parte de um módulo chamado "Person", a classe de Factory deve ser batizada de "PersonDAOFactory". Cada método desta classe retornará o DAO de um objeto deste módulo. Para maiores informações sobre esse objeto leia no tópico da Persistência.
Sufixos da Camada de Negócio (CRUD)
- Task: O sufixo Task é dado para as tarefas do BISCore. Tarefas são classes de delegação de função que permitem serem disparadas por outros serviços, como o BISWorkflow ou o BISScheduler. Leia mais no tópico BISTask.
Métodos e Funções
Alguns métodos muito usados já tem um prefixo definido, verifica abaixo a lista dos prefixos dos métodos o que se espera que um método com esse prefixo faça.
|
|
| Prefixos & Sufixos
|
| Alguns métodos também tem sufixos definidos, isso significa que para cada sufixo um método tem alguma variação no seu funcionamento.
|
|
- find: Os métodos de find são específicos para procurar/buscar algum objeto. Geralmente vindo do banco de dados.
- update: Atualiza um objeto. Este método manipula algum objeto para deixa-lo atualizado. Por exemplo, um método que recebe um VO e o atualiza no banco de dados, ou um método chamado quando ocorre algum evento (Ex: seleção de item pelo usuário) e precisa atualizar alguma informação (Ex: Habilitar/Desabilitar um botão. Note que este método não trata o disparo do evento, mas sim realizar alguma tarefa de atualização de objeto. Para tratar eventos verifique o prefixo 'changed'.
- change: São métodos de update mais diretos, servem principalmente para atualizar apenas algum atributo do objeto no banco de dados, sem ter que passar ele todo para o core. Assim este método recebe somente um identificador e o novo valor a ser definido no objeto. A ideia por trás deste tipo de método é evitar que o objeto seja todo carregado, e na atualização seja todo re validado perdendo em performance.
- insert: Métodos chamados para inserir um objeto em algum contexto. Como por exemplo inserir um novo VO no banco de dados.
- process: Métodos que recebem um objeto e fazem algum processamento ou a partir deles. Costumam retornar o objeto manipulado embora não seja obrigatório, principalmente quando o processamento manipula mais de um método por vez.
- changed: Como a maior parte dos eventos de apresentação são tratados em anonymous inner classes para evitar a codificação de uma classe só para tratar um evento pequeno, ou desde o Java 8 por expressões Lambda, dentro deste listener colocamos apenas a chamada para um método na classe principal, este método terá o prefixo 'changed'. Exemplo, imagine o um ComboBox chamado 'sector', ao se alterar o valor deste combo chamaremos o método 'changedSectorValue()'. E dentro deste método implementamos o que for necessário.