Orientação a Objetos e SOLID para Ninjas Projetando classes flexíveis
Mauricio AnicheOrientação a Objetos e SOLID para Ninjas: Projetando classes flexíveis
Prefácio por Guilherme Silveira
São 20:54. Na pausa do filme, ligo para o Aniche. Não sei o que fazer com o código que vi hoje, são cinco minutos, que viram dez, vinte. Uma conversa no dia seguinte, um e-mail na lista de discussão da Caelum ou do Alura.
Não foi uma, duas, nem vinte vezes. A vantagem de se conhecer um especialista é em uma conversa simples para resolver um problema de design surgirem outras vinte questões que não levantamos antes.
Criar qualquer coisa é fácil, um novo sistema, uma grande pedra. Difícil é mantê-la de pé, moldá-la. Sua fundação, seu design, são esculpidos e revelados pelos que se dedicam a essa tarefa, revelando dentro daquele bloco o significado de sua existência.
Entender como diversas técnicas de engenharia de software, de qualidade de código, afetam nosso desenvolvimento no dia a dia é um desafio que nós todos, durante nossa busca pelo crescimento profissional, devemos almejar. E este livro reflete diversos dos tópicos que formam a base das conversas que tenho com o Aniche, a quem peço o conselho, a confirmação ou o questionamento do que fiz ou pretendo fazer.
Entender como reduzir um problema do mundo real a um problema de design é a ideia que o livro propõe. O resultado é visível no primeiro uso dessas técnicas, seja aqui no livro ou no mundo real, sentimos como é mais fácil adicionar funcionalidades ou modificar comportamentos, uma vez que nos preocupamos mais com como fizemos, não só com o quê.
Claro, como toda prática, devemos saber dosar, quanto e até quando vale a pena utilizá-las. "Sabido", o Aniche nos mostra o caminho por meio de exemplos do mundo real onde percebemos e nos identificamos aos poucos com os problemas que surgem no código, para então criarmos juntos uma solução, uma proposta de mudança no design.
Nossa lição de casa é, da mesma maneira que no livro, criarmos projetos de maior qualidade, para que possamos manter uma relação saudável com nosso trabalho, nossa obra, por mais tempo e com mais produtividade.
Amanhã, especificamente, não ligarei para o Aniche para aprender mais sobre meu design, poderei revisar diversas de suas recomendações por este livro.
- Guilherme Silveira
Prefácio por Ismar Frango Silveira
Caro(a) leitor(a),
Seja você um(a) expert em programação, conhecedor(a) pleno de uma dúzia de linguagens; ou um(a) programador(a) dedicado(a) a uma – quiçá duas – linguagens diferentes; ou um(a) novato(a) que se perde no infindável mar de ponto e vírgulas e parênteses; ou ainda simplesmente uma pessoa curiosa, querendo compreender esse universo que faz com que pessoas aparentemente normais passem noites a fio sem dormir à base de café escrevendo sentenças ilegíveis em alguma "língua" estranha: afirmo, sem te conhecer, que este livro é para você.
Caso os cabelos brancos já sejam maioria entre os fios que restaram em sua cabeça, possivelmente você deve ter acompanhado a implementação dos conceitos rudimentares de objetos em Simula-67. Deve também ter visto o paulatino aparecimento de linguagens imperativas com a inclusão de alguns elementos “diferentes” (como tipos abstratos de dados e encapsulamento). Possivelmente você tomou contato com a implementação plena dos conceitos da uma teoria (que seria conhecida como Orientação a Objetos) na linguagem Smalltalk – parte do visionário projeto Dynabook da Xerox – pelos idos de 1980.
Tempos árduos esses: o advento da computação pessoal estava dando seus primeiros passos no mundo e trazia consigo um enorme potencial de demanda para o desenvolvimento de software. Pela primeira vez, era possível que o valor agregado de um software sobrepujasse o hardware, ainda caro naquela época. Em especial, o Brasil, por ser refém de uma reserva de mercado que nos alijava do desenvolvimento tecnológico mundial, tentava dar sôfregos passos no que diz respeito à criação de um mercado interno e à formação de profissionais para a área.
Era mais fácil encontrar uma nota de cem cruzeiros (seja lá o quanto isso valesse, dada a instabilidade econômica da época) do que um programador com formação adequada. Que esse programador houvesse ouvido falar sobre Orientação a Objetos, ainda mais raro. Se você se identificou com esta época, possivelmente frequentou os bancos universitários em algum curso de Matemática ou Engenharia, já que Bacharelados em Ciência da Computação eram raridade por essas bandas (o primeiro foi na Unicamp, em 1969). Ou foi curioso(a) – e corajoso(a) - o suficiente para aprender sozinho.
Talvez você não tenha tanto cabelos brancos assim e palavras como C++, Delphi, Java e C# lhe soem mais familiares. Se este é o seu caso, possivelmente você deve ter visto, entre meados da década de 1980 até o início deste século, o surgimento de uma dessas linguagens em um cenário bastante diferente. Ao fugir do "purismo" de Smalltalk e bebendo (algumas, se embriagando) da fonte de linguagens imperativas, como C e Pascal, estas linguagens caíram no gosto popular e impulsionaram fortemente o modelo de Programação Orientada a Objetos.
Métodos de Análise e Projeto orientados a objetos surgiram e desapareceram neste período, até a unificação, ao menos no que diz respeito aos diagramas, proposta pela UML a partir de 1997. Com a padronização da pilha de protocolos de Internet e o surgimento da WWW, conceitos de Orientação a Objetos foram inspiradores para linguagens que se tornaram populares neste novo cenário, como Javascript e PHP. Formou-se assim o caldo que deu origem ao cenário atual, em que temos as linguagens que seguem, total ou parcialmente, o Paradigma da Orientação a Objetos como dominantes em um mercado cada vez mais complexo e competitivo.
Esse período trouxe uma evolução nunca antes vista nos conceitos de computação pessoal: os microcomputadores foram abrindo espaço para notebooks, cada vez mais compactos e potentes (troque-se o note por net, ultra ou o próximo termo da moda); estes, por sua vez, vêm sendo sobrepujados por dispositivos móveis (de smartphones e tablets a smartclocks e todo tipo de gadget que vem aparecendo), segmento igualmente beneficiado pelo barateamento e compactação do hardware. E tudo isso com crescentes possibilidades de conectividade e ubiquidade (independente da sua Wifi ou conexão 3G não funcionar muito bem na hora que você mais precisa). As linguagens de programação desempenharam um papel importante, ao evoluírem junto com o hardware para atender as diversas novas demandas de desenvolvimento.
Porém, vai que você seja um(a) novato(a) - ou simplesmente curioso(a) - nesse fantástico universo do desenvolvimento de software. Se assim for, prepare-se! O cenário que se desenhou no século XXI é desafiador e emocionante: ao mesmo tempo em que temos incríveis IDEs que parecem fazer todo o “trabalho sujo” da programação (corrigir sintaxe, refatorar código, aplicar padrões automaticamente, etc.), os requisitos de software estão cada vez mais sofisticados e complexos – a turma dos cabelos brancos não tinha que se preocupar com mobilidade, interfaces responsivas e segurança, por exemplo. As populares linguagens orientadas a objeto vêm evoluindo de forma a se tornarem multiparadigmas – ou seja, mesclando construtos oriundos da programação funcional, concorrente, entre outras.
Nesse admirável mundo novo, compreender, de forma precisa, a miríade de conceitos e técnicas que orbitam a área de Orientação a Objetos não é uma tarefa fácil. Compreender esses conceitos e explicá-los de maneira cristalina, em uma linguagem fluida e agradável, ilustrando conceitos complexos com exemplos didáticos, é o desafio ao qual Mauricio Aniche se lançou na confecção deste livro. Não tenho a menor dúvida de que ele atingiu plenamente seu objetivo – e convido você, leitor(a), a comprovar isso.
Boa leitura!
- Ismar Frango Silveira
Sumário
- 1 - Orientação a Objetos, pra que te quero?
- 1.1 - Qual o público deste livro?
- 2 - A coesão e o tal do SRP
- 2.1 - Um exemplo de classe não coesa
- 2.2 - Qual o problema dela?
- 2.3 - Em busca da coesão
- 2.4 - Uma pitada de encapsulamento
- 2.5 - Quando usar métodos privados?
- 2.6 - Falta de coesão em controllers
- 2.7 - Inveja da outra classe
- 2.8 - SRP ─ Single Responsibility Principle
- 2.9 - Separação do modelo, infraestrutura, e a tal da arquitetura hexagonal
- 2.10 - Conclusão
- 3 - Acoplamento e o tal do DIP
- 3.1 - Qual o problema dela?
- 3.2 - Estabilidade de classes
- 3.3 - Buscando por classes estáveis
- 3.4 - DIP ─ Dependency Inversion Principle
- 3.5 - Um outro exemplo de acoplamento
- 3.6 - Dependências lógicas
- 3.7 - Conclusão
- 4 - Classes abertas e o tal do OCP
- 4.1 - Qual o problema dela?
- 4.2 - OCP ─ Princípio do Aberto-Fechado
- 4.3 - Classes extensíveis
- 4.4 - A testabilidade agradece!
- 4.5 - Um exemplo real
- 4.6 - Ensinando abstrações desde a base
- 4.7 - Conclusão
- 5 - O encapsulamento e a propagação de mudanças
- 5.1 - Qual o problema dela?
- 5.2 - Intimidade inapropriada
- 5.3 - Um sistema OO é um quebra-cabeças
- 5.4 - Tell, Don't Ask
- 5.5 - Procurando por encapsulamentos problemáticos
- 5.6 - A famosa Lei de Demeter
- 5.7 - Getters e setters pra tudo, não!
- 5.8 - Corrigindo o código inicial
- 5.9 - Modelos anêmicos
- 5.10 - Conclusão
- 6 - Herança x composição e o tal do LSP
- 6.1 - Qual o problema dela?
- 6.2 - LSP ─ Liskov Substitutive Principle
- 6.3 - O exemplo do quadrado e retângulo
- 6.4 - Acoplamento entre a classe pai e a classe filho
- 6.5 - Favoreça a composição
- 6.6 - Herança para DSLs e afins
- 6.7 - Quando usar herança então?
- 6.8 - Pacotes: como usá-los?
- 6.9 - Conclusão
- 7 - Interfaces magras e o tal do ISP
- 7.1 - Interfaces coesas e magras
- 7.2 - Pensando na interface mais magra possível
- 7.3 - E os tais dos repositórios do DDD?
- 7.4 - Fábricas ou injeção de dependência?
- 7.5 - Conclusão
- 8 - Consistência, objetinhos e objetões
- 8.1 - Construtores ricos
- 8.2 - Validando dados
- 8.3 - Teorema do bom vizinho e nulos para lá e para cá
- 8.4 - Tiny Types é uma boa ideia?
- 8.5 - DTOs do bem
- 8.6 - Imutabilidade x mutabilidade
- 8.7 - Classes que são feias por natureza
- 8.8 - Nomenclatura de métodos e variáveis
- 8.9 - Conclusão
- 9 - Maus cheiros de design
- 9.1 - Refused Bequest
- 9.2 - Feature Envy
- 9.3 - Intimidade inapropriada
- 9.4 - God Class
- 9.5 - Divergent Changes
- 9.6 - Shotgun Surgery
- 9.7 - Entre outros
- 10 - Métricas de código
- 10.1 - Complexidade ciclomática
- 10.2 - Tamanho de métodos
- 10.3 - Coesão e a LCOM
- 10.4 - Acoplamento aferente e eferente
- 10.5 - Má nomenclatura
- 10.6 - Como avaliar os números encontrados?
- 10.7 - Ferramentas
- 11 - Conclusão
- 11.1 - Onde posso ler mais sobre isso?
- 11.2 - Obrigado!
Dados do produto
- Número de páginas:
- 155
- ISBN:
- 978-85-5519-037-7
- Data publicação:
- 03/2015