Desafio de programação: Ok, então você pode se perguntar por que você programa como dessa maneira como este sujeito acima, mas a resposta é se você tentar fazer isso de outra maneira será forçado a pensar de uma forma diferente e que isso pode realmente beneficiar você a longo prazo ao escrever código OO. Aqui está o desafio:
A ThoughtWorks lançou um novo livro dos Programadores Pragmáticos, há um fascinante ensaio chamado ‘Calisthenics objeto’por Jeff Bay. É um exercício detalhado para aperfeiçoar a escrita das pequenas rotinas que demonstram caracterizar boas implementações OO. Se você tiver desenvolvedores que precisam de melhorar a sua capacidade de escrever rotinas OO, eu sugiro que você tenha atento neste ensaio. vou tentar resumir a abordagem de Bay aqui.
Ele sugere escrever um programa de 1000 linhas com as restrições listadas abaixo. Estes constrangimentos são destinados a ser excessivamente restritiva, de modo a forçar os desenvolvedores fora do sulco processual. Eu garanto que se você aplicar esta técnica, seu código irá mover acentuadamente no sentido de orientação a objetos. As restrições (que devem ser impiedosamente impostas neste exercício) são:
1. Use apenas um nível de recuo por método. Se você precisar de mais de um nível, você precisa criar um segundo método e chamá-lo desde o início. Esta é uma das restrições mais importantes do exercício.
2. Não use a palavra-chave ‘else’. Teste para uma condição com uma instrução if e sair da rotina se não for atendida. Isso evita que exista um encadeamento if-else; e cada rotina faz apenas uma coisa. Deste jeito você está “pegando” a idéia.
3. Enrole todos os primitivos e strings. Este aborda diretamente “obsessão primitiva.” Se você quiser usar um inteiro, você primeiro tem que criar uma classe (mesmo uma classe interna) para identificar que é verdadeiro papel. Então códigos postais são um objeto não um inteiro, por exemplo. Isto faz para código muito mais clara e mais testável.
4. Use apenas um ponto por linha. Este passo impede de alcançar profundamente em outros objetos para chegar a campos ou métodos, e, assim, conceitualmente quebrar encapsulamento.
5. Não abrevie nomes. Essa restrição evita a verbosidade processual que é criado por certas formas de redundância, se você tem que digitar o nome completo de um método ou variável, é provável que você gaste mais tempo pensando sobre o seu nome. E você vai evitar que objetos chamados Ordenacao com métodos RealizarOrdenacao(). Em vez disso, seu código terá mais chamadas como Ordenacao.Realizar().
6. Mantenha as entidades de pequeno porte. Isto significa que não mais do que 50 linhas por classe e não mais de 10 classes por pacote. As 50 linhas por restrição de classe é crucial. Não é só forçar concisão e manter aulas focadas, mas isso significa que a maioria das classes pode caber em uma única tela em qualquer editor / IDE.
7. Não utilize quaisquer classes com mais de duas variáveis de instância. Esta é talvez a restrição mais difícil. O ponto de Bay é que, com mais de duas variáveis de instância, há quase certamente uma razão para subgrupo algumas variáveis em uma classe separada.
8. Use coleções de primeira classe. Qualquer classe que contém uma coleção não deve conter outras variáveis de membro. Cada coleção é embrulhado em sua própria classe, então agora comportamentos relacionados com a recolha de ter uma casa. Você pode achar que os filtros se tornar uma parte desta nova classe. Além disso, sua nova classe pode lidar com atividades como a junção de dois grupos juntos ou aplicar uma regra para cada elemento da ideia group.The é uma extensão da obsessão primitiva. Se você precisar de uma classe que é um subsume a coleção, em seguida, escrevê-lo dessa forma.
9. Não use setters, getters ou propriedades. Esta é uma abordagem radical de aplicação de encapsulamento. Ela também requer a implementação de abordagens de injeção de dependência e aderência à máxima “diga, não pergunte.”
Tomadas em conjunto, essas regras impõem um encapsulamento restritivo sobre os desenvolvedores e força a pensar ao longo das linhas OO. Afirmo que ninguém que escreve um projeto de 1.000 linhas sem violar essas regras vai rapidamente tornar-se muito melhor em OO. Eles podem então, se quiserem, relaxar as restrições um pouco, mas como Bay aponta, não há nenhuma razão para fazê-lo. Sua equipe acaba de terminar um projeto de 100.000 linhas dentro destas restrições “.
fonte:: http://goo.gl/Wly2s4
IFES - BSI 