deve comecar com uma lista de variaveis de preferencia nesta ordem:1. variaveis publicas e estaticas2. variaveis privadas e estaticas3. variaveis privadasDepois das variaveis vem os metodos publicos. Os metodos privados aparecem depois de suas chamadas. Assim como os metodos, as classes tambem devem ser pequenas. Ninguem gosta de encontrar classes gigantes onde e dificil ate mesmo de se encontrar dentro delas. Mas a pergunta e: O quao pequenas elas devem ser?O nome da classe deve representar a sua responsabilidade. Tentar fazer uma breve descricao da classe, explicando o que ela faz pode ajudar a escolher o nome certo. Esta descricao deve ter no maximo 25 palavras e nao conter palavras como mas, e, ou, se, pois expressam mais de uma coisa mostrando que ha mais de uma responsabilidade.Outra maneira de descobrir o tamanho ideal da classe e analisarmos suas responsabilidades. O Principio da Unica Responsabilidade (Single Responsibility Principle) diz que uma classe deve ter uma, e apenas uma razao para mudar. Quando uma classe possui mais que um motivo para ser alterada e porque provavelmente ela esta fazendo mais coisas do que devia, ou seja, ela tem mais de um objetivo. O principio nos da definicoes de responsabilidade e uma diretriz para o tamanho de uma classe. Tentar identificar responsabilidades nos ajuda a melhorar nosso codigo e criar melhores abstracoes.Para concluir, queremos nosso sistema com pequenas classes, cada uma com uma unica responsabilidade, tendo uma razao para mudar e colaborando com outras para alcancar o comportamento desejado do sistema.Design emergenteDesign emergente e um design que nunca e o final, sempre esta em evolucao. Para conseguirmos criar boas estruturas de codigo tornando mais facil de aplicar principios como SRP e DIP, e assim facilitar a criacao de um de bom design de software, Kent Beck estipulou 4 regras para um design simples (Simple Design):1. Rode todos os testesFazer um sistema testavel nos obriga e usar boas praticas como classes e metodos pequenos de apenas uma responsabilidade.Quanto mais testes fazemos mais e melhores maneiras e principios seguiremos para evitar o acoplamento de nosso codigo. Lembre-se, um sistema testavel possui sempre todos os seus testes passando. Um sistema que nao e testavel, nao e verificavel e assim nao pode ser entregue para producao.2. Remova duplicacaoDuplicacao e o primeiro inimigo de um bom design, ela representa trabalho e riscos adicionais alem de uma maior e desnecessaria complexidade. Ela se manifesta em linhas de codigos iguais ou parecidas alem de aparecerem nas implementacoes. Usar padroes como Template Method e uma saida para remover duplicacoes mais complexas.3. Expresse sua intencaoEscrever codigo que nos entendemos e facil pois estamos concentrados e ligados no problema que estamos tentando resolver. Mas o proximo que pegar o codigo para fazer manutencao, nao estara tao ligado ao problema como voce estava quando implementou a solucao.Expressar-se bem no codigo pode trazer grandes beneficios para o desenvolvimento de um sistema. Alem de poupar tempo de quem o mantem. Voce pode expressar-se bem em seu codigo escolhendo bons nomes, deixando metodos e classes pequenas, separando responsabilidades. Lembre-se que voce pode sem o proximo a ler este