1. A primeira letra do nome da turma deve ser maiúscula. A primeira letra dos campos, métodos e objetos (handles) deve ser minúscula. Tal como acontece com todos os identificadores, todas as palavras contidas nele devem estar próximas umas das outras, com a primeira letra da palavra intermediária em maiúscula. Por exemplo:
Copie o código da seguinte forma: ThisIsAClassName
thisIsMethodOrFieldName
Se um caractere inicializador constante aparecer na definição, coloque todas as letras em maiúscula no identificador de tipo básico final estático. Isto irá marcá-los como constantes de tempo de compilação.
Os pacotes Java são um caso especial: estão todos em letras minúsculas, até mesmo as palavras do meio. Para nomes de extensão de nome de domínio, como com, org, net ou edu, etc., todos devem estar em letras minúsculas (essa também é uma das diferenças entre Java 1.1 e Java 1.2).
2. Ao criar uma classe de uso geral, adote a “forma clássica” e inclua definições dos seguintes elementos:
Copie o código do código da seguinte forma:
é igual()
código hash()
toString()
clone()（implementar Clonável）
implementar serializável
3. Para cada classe criada, considere colocar um main(), que contém o código para testar essa classe. Para usar classes de um projeto, não precisamos excluir o código de teste. Se forem feitas alterações de qualquer tipo, é fácil retornar aos testes. O código também serve como exemplo de como usar classes.
4. O método deve ser projetado em uma unidade funcional breve, que possa ser usada para descrever e implementar uma parte de interface de classe descontínua. Idealmente, a abordagem deve ser concisa e direta. Se o comprimento for grande, considere dividi-lo em pedaços mais curtos de alguma forma. Fazer isso também facilita a reutilização de código dentro de uma classe (às vezes, os métodos devem ser muito grandes, mas ainda assim devem fazer apenas a mesma coisa).
5. Ao projetar uma classe, coloque-se no lugar do programador cliente (o método de uso da classe deve ser muito claro). Em seguida, coloque-se no lugar da pessoa que gerencia o código (antecipe quais tipos de alterações provavelmente serão feitas e pense em maneiras de torná-las mais simples).
6. Faça a aula o mais curta e concisa possível e resolva apenas um problema específico. Aqui estão algumas sugestões para design de classe:
1. Uma instrução switch complexa: considere usar o mecanismo "polimórfico"
2. Um grande número de métodos envolve operações com tipos muito diferentes: considere usar diversas classes para implementá-los separadamente.
3. Muitas variáveis-membro têm características muito diferentes: considere usar várias classes
7. Torne tudo o mais “privado” possível. Você pode tornar uma parte da biblioteca “pública” (um método, uma classe, um campo, etc.) para que ela nunca possa ser retirada. Se você forçá-lo, isso poderá destruir o código existente de outras pessoas, forçando-as a reescrevê-lo e projetá-lo. Se você publicar apenas o que deve publicar, fique à vontade para alterar qualquer outra coisa. Em ambientes multithread, a privacidade é um fator particularmente importante. Somente os campos privados podem ser protegidos contra o uso não sincronizado.
8. Tenha cuidado com a “síndrome do objeto gigante”. Para alguns novatos que estão acostumados com o pensamento de programação sequencial e são novos no campo OOP, eles geralmente gostam de escrever primeiro um programa de execução sequencial e depois incorporá-lo em um ou dois objetos enormes. De acordo com os princípios de programação, os objetos devem expressar o conceito da aplicação, e não a aplicação em si.
9. Se você tiver que fazer alguma programação feia, você deve pelo menos colocar o código dentro de uma classe.
10. Sempre que você descobrir que as classes estão intimamente integradas, será necessário considerar se deve usar classes internas para melhorar o trabalho de codificação e manutenção (consulte "Melhorando o código com classes internas" no Capítulo 14, Seção 14.1.2).
11. Adicione comentários com o maior cuidado possível e use a sintaxe do documento de comentários javadoc para gerar sua própria documentação do programa.
12. Evite usar “números mágicos”. Esses números são difíceis de encaixar bem no código. Se você precisar modificá-lo no futuro, sem dúvida se tornará um pesadelo, porque você não tem ideia se “100” se refere ao “tamanho do array” ou “algo totalmente diferente”. Portanto, devemos criar uma constante, dar-lhe um nome convincente e descritivo e usar identificadores de constante em todo o programa. Isso torna o programa mais fácil de entender e manter.
13. Quando se trata de construtores e exceções, geralmente você deseja lançar novamente qualquer exceção capturada no construtor se isso causar falha na criação desse objeto. Dessa forma, o chamador não continuará pensando cegamente que o objeto foi criado corretamente.
14. Depois que o programador cliente terminar de usar o objeto, se sua classe exigir algum trabalho de limpeza, considere colocar o código de limpeza em um método bem definido, usando um nome como cleanup() para indicar claramente seu uso. Além disso, um sinalizador booleano pode ser colocado dentro da classe para indicar se o objeto foi limpo. No método finalize() da classe, certifique-se de que o objeto foi limpo e que uma classe que herda de RuntimeException foi descartada (se ainda não o foi), indicando assim um erro de programação. Antes de adotar uma solução como essa, certifique-se de que finalize() funcione em seu sistema (pode ser necessário chamar System.runFinalizersOnExit(true) para garantir esse comportamento).
15. Em um escopo específico, se um objeto precisar ser limpo (não processado pelo mecanismo de coleta de lixo), use o seguinte método: inicialize o objeto, se for bem-sucedido, insira imediatamente um bloco try contendo uma cláusula final para iniciar o trabalho de limpeza; .
16. Se você precisar substituir (cancelar) finalize() durante o processo de inicialização, lembre-se de chamar super.finalize() (se Object pertencer à nossa superclasse direta, isso não é necessário). No processo de substituição de finalize(), a chamada para super.finalize() deve ser a última ação, não a primeira, para garantir que os componentes da classe base ainda sejam válidos quando forem necessários.
17. Ao criar coleções de objetos de tamanho fixo, transfira-os para um array (especialmente se você planeja retornar esta coleção de um método). Dessa forma, podemos aproveitar os benefícios da verificação do tipo de array em tempo de compilação. Além disso, o destinatário do array pode não precisar "lançar" o objeto no array para usá-lo.
18. Tente usar interfaces em vez de classes abstratas. Se você sabe que algo será uma classe base, sua primeira opção deve ser transformá-lo em uma interface. Somente quando você precisar usar definições de método ou variáveis de membro, será necessário transformá-lo em uma classe abstrata. Uma interface basicamente descreve o que o cliente deseja fazer, enquanto uma classe é dedicada (ou permite) detalhes específicos de implementação.
19. Dentro do construtor, faça apenas o trabalho necessário para colocar o objeto no estado correto. Sempre que possível, evite chamar outros métodos, pois esses métodos podem ser substituídos ou cancelados por outros, produzindo resultados imprevisíveis durante o processo de construção (consulte o Capítulo 7 para obter detalhes).
20. Os objetos não devem conter apenas alguns dados; o seu comportamento também deve ser bem definido.
21. Ao criar uma nova turma com base em uma turma existente, selecione primeiro "Novo" ou "Criar". Esta questão só deve ser considerada se os seus próprios requisitos de design precisarem ser herdados. Se a herança for usada onde uma nova criação for permitida, todo o design se tornará desnecessariamente complexo.
22. Use herança e cobertura de método para expressar a diferença entre comportamentos e use campos para expressar a diferença entre estados. Um exemplo muito extremo é representar cores através de herança de classes diferentes, o que definitivamente deve ser evitado: use um campo "cor" diretamente.
23. Para evitar problemas durante a programação, certifique-se de que cada nome corresponda a apenas uma classe, onde quer que seu caminho de classe aponte. Caso contrário, o compilador poderá primeiro encontrar outra classe com o mesmo nome e reportar uma mensagem de erro. Se você suspeitar que encontrou um problema no caminho da classe, tente procurar um arquivo .class com o mesmo nome em cada ponto inicial do caminho da classe.
24. Ao usar "adaptadores" de eventos em Java 1.1 AWT, é particularmente fácil encontrar uma armadilha. Se um método adaptador for substituído e o método ortográfico não for particularmente específico, o resultado final será adicionar um novo método em vez de substituir o método existente. No entanto, como isso é perfeitamente legal, você não receberá nenhuma mensagem de erro do compilador ou do sistema de tempo de execução, mas seu código simplesmente se comportará incorretamente.
25. Use soluções de design razoáveis para eliminar "pseudofunções". Ou seja, se você precisar criar apenas um objeto da classe, não se limite antecipadamente à aplicação e adicione um comentário "gerar apenas um deles". Por favor, considere encapsulá-lo em um formato "filho único". Se você tiver muito código disperso no programa principal usado para criar seus próprios objetos, considere adotar uma solução criativa para encapsular esse código.
26. Tenha cuidado com a “paralisia por análise”. Lembre-se, não importa o que aconteça, você precisa entender o status de todo o projeto com antecedência e depois examinar os detalhes. Como você tem uma noção da situação geral, pode reconhecer rapidamente alguns fatores desconhecidos e evitar cair na “lógica morta” ao examinar os detalhes.
27. Tenha cuidado com a “otimização prematura”. Faça-o rodar primeiro, pense em ficar mais rápido depois, mas só otimize se for preciso e se for comprovado que existe um gargalo de performance em alguma parte do código. A menos que você use ferramentas especializadas para analisar gargalos, provavelmente estará desperdiçando seu tempo. O custo implícito das melhorias de desempenho é que seu código se torna mais difícil de entender e de manter.
28. Lembre-se de que você gasta muito mais tempo lendo código do que escrevendo. Um design claro resulta em um programa fácil de entender, mas comentários, explicações cuidadosas e alguns exemplos são frequentemente inestimáveis. Eles são muito importantes, tanto para você quanto para quem te segue. Se você ainda duvida disso, imagine sua frustração ao tentar encontrar informações úteis na documentação on-line do Java, e você poderá se convencer.
29. Se você acha que realizou uma boa análise, projeto ou implementação, mude ligeiramente sua perspectiva de pensamento. Tente convidar pessoas de fora, não necessariamente especialistas, mas pessoas de outras partes da empresa. Peça-lhes que olhem para o seu trabalho com olhos completamente novos e vejam se conseguem identificar problemas para os quais você era cego. Ao adotar esse método, muitas vezes podemos identificar alguns problemas-chave no estágio mais adequado para modificação e evitar a perda de dinheiro e energia causada pela resolução de problemas após o lançamento do produto.
30. Um bom design pode trazer os maiores retornos. Em suma, muitas vezes leva muito tempo para encontrar a solução mais adequada para um determinado problema. Mas depois de encontrar o método certo, seu trabalho futuro será muito mais fácil e você não terá que suportar horas, dias ou meses de luta dolorosa. Nosso trabalho árduo trará as maiores recompensas (mesmo as imensuráveis). E porque me esforcei muito nisso, finalmente consegui um excelente plano de design, e a emoção do sucesso também é emocionante. Resista à tentação de apressar o trabalho, que muitas vezes não vale o esforço.