Skip to content

Instantly share code, notes, and snippets.

@mvoto
Last active January 4, 2016 16:13
Show Gist options
  • Save mvoto/4797943e7fc5e7f84642 to your computer and use it in GitHub Desktop.
Save mvoto/4797943e7fc5e7f84642 to your computer and use it in GitHub Desktop.
Notas sobre o livro Practical Oriented Object Design in Ruby by Sandi Metz

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment