Notas sobre o livro Practical Oriented Object Design in Ruby by Sandi Metz

pood_notes.md

Intro

A leitura deste livro tem como fim o aperfeiçoamento profissional e mudança no modo de enxergar o desenvolvimento. Algumas informações são essenciais para isto, como: boas práticas sempre levam a um bom design de código.

Dicas

• Single Responsability: Perguntar para a classe sobre seu próprio método, ex.: Carro qual a sua cor ? Isto ajuda a definir se um método faz sentido para a aquela classe, o que ajuda a definir que uma classe deve fazer apenas o que é de sua responsabilidade. Se perguntarmos: Carro qual é a capacidade do seu tanque ? talvez até faça sentido, mas conforme a aplicação vá crescendo, faça sentido criar uma classe Tanque que saiba responder a pergunta de qual a sua capacidade

• Single Responsability: Utilizar sempre que possível attr_accessor _reader e writer - se for necessário incluir alguma lógica específica e/ou complexa para definir algum atributo, é melhor que este mesmo esteja isolado em um lugar(como os attr já o faz).

• Managing Dependencies: Utilizar dependency injection(receber uma instância de outra classe como mensagem) ao invés de inicializar ou defini-lo dentro de sua classe.

• Managing Dependencies: Utilizar hash de args em vez de parâmetros com ordem fixa nos métodos, a menos que sejam poucos e simples parâmetros. Também é recomendado definir valores padrôes em um método default e mergea-los, em caso de complexidade de valores default.

• Designing Interfaces: Desenhar diagrama de sequência é uma maneira de tentar iniciar o design podendo errar e com baixo custo.

• Designing Interfaces: Utilizar a abordagem de um mensagens. Um objeto não é criado para enviar/responder uma mensagem e não o contrário.

• Designing Interfaces: Perguntar o quê e não como para uma mensagem. Isto ajuda a definir interfaces públicas, perguntar algo em vez de como para uma classe/instância. O como fica encapsulado na classe/instância como métodos privados.

• Law of Demeter: Evitar encadeamento de métodos, principalmente se forem objetos / comportamentos diferentes. Esta lei permite o dev a se atentar à problemas de design, não se pode reaproveitar um 'estado' do meio do encadeamento, por exemplo: bycicle.tire.rotate não se pode aproveitar o bycicle.tire.

• Duck Typing: A definição é de não ligar tanto para a classe, mas sim para o comportamento, as mensagens. Se faz quack e anda como um pato, então é um pato. É o ato de extrair tipos virtuais de interfaces públicas, baseados no que eles fazem em vez do que eles são de fato.

• Duck Typing: reduz riscos e aumenta flexibilidade, tornando a aplicação fácil de manter e de alterar