
Length15h 32m
About this audiobook
Do meu ponto de vista, um bom design de software é a essência de todo projeto de software bem-sucedido. Ainda assim, apesar de seu papel fundamental, há tão pouca literatura sobre o assunto e muito poucos conselhos sobre o que fazer e como fazer as coisas corretamente. Por quê? Bem, porque é difícil. Muito difícil. Provavelmente a faceta mais difícil de escrever software que temos que enfrentar. E isso porque não existe uma única solução "certa", nenhum conselho "de ouro" para passar pelas gerações de desenvolvedores de software. Sempre depende. Apesar dessa limitação, darei conselhos sobre como projetar um software bom e de alta qualidade. Fornecerei princípios de design, diretrizes de design e padrões de design que ajudarão você a entender melhor como gerenciar dependências e transformar seu software em algo com o qual você possa trabalhar por décadas. Como afirmado anteriormente, não há conselho "de ouro", e este livro não contém nenhuma solução definitiva ou perfeita. Em vez disso, tento mostrar os aspectos mais fundamentais de um bom software, os detalhes mais importantes, a diversidade e os prós e contras de diferentes designs. Também formularei objetivos de design intrínsecos e demonstrarei como atingir esses objetivos com o C++ moderno.
Audiobook details
GenreTechnology
Length15 hrs 32 mins
Narrated byListen with 1,000+ voices
FormateBook with Audio
Publish dateSep 29, 2022
LanguagePortuguese
Table of contents
1Projeto de software C++
96A filosofia C++ moderna: semântica de valor
2Prefácio
97Semântica de valor: um segundo exemplo
3Por que escrevi este livro
98Prefira usar a semântica de valor para implementar padrões de design
4Sobre o que é este livro
99Diretriz 23: Prefira uma implementação de estratégia e comando baseada em valor
5Design de software
100Introdução ao std::function
Show all chaptersShow less
6C++ moderno
101Refatorando o desenho de formas
7Padrões de design
102Referências de desempenho
8Para quem é este livro
103Analisando as deficiências da solução std::function
9Como este livro está estruturado
104Capítulo 6. Os Padrões de Projeto do Adaptador, Observador e CRTP
10Convenções utilizadas neste livro
105Diretriz 24: Use Adaptadores para Padronizar Interfaces: O padrão de design do adaptador explicado
11Usando exemplos de código
106O padrão de design do adaptador
12Capítulo 1. A Arte do Design de Software
107Adaptadores de objetos versus adaptadores de classe
13Diretriz 1: Entenda a importância do design de software
108Exemplos da Biblioteca Padrão
14Recursos não são design de software
109Comparação entre Adaptador e Estratégia
15Design de software: a arte de gerenciar dependências e abstrações
110Adaptadores de função
16Os três níveis de desenvolvimento de software
111Analisando as deficiências do padrão de design do adaptador
17O foco nos recursos
112Diretriz 25: Aplicar Observadores como um Mecanismo de Notificação Abstrata: O padrão de projeto do observador explicado
18O foco no design de software e princípios de design
113O padrão de projeto do observador
19Diretriz 2: Design para Mudança
114Uma implementação clássica do observador
20Separação de preocupações
115Uma implementação de observador com base na semântica de valor
21Um exemplo de acoplamento artificial
116Analisando as deficiências do padrão de projeto do observador
22Acoplamento Lógico versus Acoplamento Físico
117Diretriz 26: Use CRTP para introduzir categorias de tipo estático
23Não se repita
118Uma motivação para o CRTP
24Evite a separação prematura de preocupações
119O padrão de design CRTP explicado
25Diretriz 3: Interfaces separadas para evitar acoplamento artificial
120O padrão de projeto CRTP
26Segregar Interfaces para Separar Preocupações
121Analisando as deficiências do padrão de projeto CRTP
27Minimizando requisitos de argumentos de modelo
122O futuro do CRTP: uma comparação entre os conceitos de CRTP e C++20
28Diretriz 4: Design para Testabilidade
123Diretriz 27: Use CRTP para classes de mixina estática
29Como testar uma função de membro privado
124Um tipo de motivação forte
30A verdadeira solução: preocupações separadas
125Usando CRTP como um padrão de implementação
31Diretriz 5: Design para Extensão
126Capítulo 7. Os Padrões de Projeto de Ponte, Protótipo e Polimorfismo Externo
32O Princípio Aberto-Fechado
127Diretriz 28: Construir pontes para remover dependências físicas
33Extensibilidade em tempo de compilação
128Um exemplo motivador
34Evite Projetos Prematuros para Extensão
129O padrão de design da ponte explicado
35Capítulo 2. A Arte de Construir Abstrações
130O padrão de design da ponte
36Diretriz 6: Aderir ao comportamento esperado das abstrações
131O idioma da espinha
37Um exemplo de violação de expectativas
132Comparação entre Bridge e Estratégia
38O Princípio da Substituição de Liskov
133Analisando as deficiências do padrão de projeto de ponte
39Crítica ao Princípio da Substituição de Liskov
134Diretriz 29: Esteja ciente dos ganhos e perdas de desempenho da ponte
40A necessidade de abstrações boas e significativas
135O impacto no desempenho das pontes
41Diretriz 7: Compreenda as semelhanças entre classes e conceitos básicos
136Melhorando o desempenho com pontes parciais
42Diretriz 8: Entenda os Requisitos Semânticos dos Conjuntos de Sobrecarga
137Diretriz 30: Aplicar Protótipo para Operações de Cópia Abstrata
43O poder das funções livres: um mecanismo de abstração em tempo de compilação
138Um Exemplo de Ovelha: Copiando Animais
44O Problema das Funções Livres: Expectativas sobre o Comportamento
139O padrão de design do protótipo explicado
45Diretriz 9: Preste Atenção à Propriedade das Abstrações
140O padrão de design do protótipo
46O Princípio da Inversão de Dependência
141Comparação entre protótipo e std::variant
47Inversão de dependência em uma arquitetura de plug-in
142Analisando as deficiências do padrão de projeto de protótipo
48Inversão de dependência por meio de modelos
143Diretriz 31: Use Polimorfismo Externo para Polimorfismo de Tempo de Execução Não Intrusivo: O padrão de projeto de polimorfismo externo explicado
49Inversão de dependência por meio de conjuntos de sobrecarga
144O padrão de projeto de polimorfismo externo
50Princípio de Inversão de Dependência versus Princípio de Responsabilidade Única
145Desenho de formas revisitado
51Diretriz 10: Considere a criação de um documento de arquitetura
146Comparação entre Polimorfismo Externo e Adaptador
52Capítulo 3. O Propósito dos Padrões de Projeto
147Analisando as deficiências do padrão de projeto de polimorfismo externo
53Diretriz 11: Compreenda o Propósito dos Padrões de Projeto
148Capítulo 8. O padrão de projeto de apagamento de tipo
54Um padrão de design tem um nome
149Diretriz 32: Considere Substituir Hierarquias de Herança por Apagamento de Tipo
55Um padrão de design carrega uma intenção
150A história do apagamento de tipos
56Um padrão de design introduz uma abstração
151O padrão de design de apagamento de tipo explicado
57Um padrão de design foi comprovado
152O padrão de design composto de apagamento de tipo
58Diretriz 12: Cuidado com Equívocos de Padrões de Projeto
153Uma implementação de eliminação de tipo de propriedade
59Padrões de design não são um objetivo
154Analisando as deficiências do padrão de projeto de apagamento de tipo
60Padrões de design não são sobre detalhes de implementação
155Comparando dois invólucros de apagamento de tipo
61Padrões de projeto não estão limitados à programação orientada a objetos ou polimorfismo dinâmico
156Segregação de Interface de Wrappers de Apagamento de Tipo
62Diretriz 13: Padrões de Design estão em toda parte
157Referências de desempenho
63Diretriz 14: Use o nome de um padrão de design para comunicar a intenção
158Uma palavra sobre terminologia
64Capítulo 4. O Padrão de Design do Visitante
159Diretriz 33: Esteja ciente do potencial de otimização do apagamento de tipo
65Diretriz 15: Design para a adição de tipos ou operações
160Otimização de buffer pequeno
66Uma solução processual
161Implementação Manual de Despacho de Função
67Uma solução orientada a objetos
162Diretriz 34: Esteja ciente dos custos de configuração de possuir embalagens de apagamento de tipo
68Esteja ciente da escolha de design no polimorfismo dinâmico
163Os custos de configuração de um invólucro de apagamento de tipo proprietário
69Diretriz 16: Use o Visitor para Estender as Operações
164Uma Implementação Simples de Apagamento de Tipo Não-Proprietário
70Analisando os problemas de design
165Uma implementação de eliminação de tipo sem proprietário mais poderosa
71O padrão de design do visitante explicado
166Capítulo 9. O Padrão de Design do Decorador
72O padrão de design do visitante: Analisando as deficiências do padrão de design do visitante
167Diretriz 35: use decoradores para adicionar personalização hierarquicamente
73Diretriz 17: Considere std::variant para Implementing Visitor
168Problema de design de seus colegas de trabalho
74Introdução ao std::variant
169O padrão de design do decorador explicado
75Refatorando o desenho de formas como uma solução não intrusiva baseada em valor
170O padrão de design do decorador
76Referências de desempenho
171Uma implementação clássica do padrão de design do decorador
77Analisando as deficiências da solução std::variant
172Um segundo exemplo de decorador
78Diretriz 18: Cuidado com o Desempenho do Visitante Acíclico
173Comparação entre decorador, adaptador e estratégia
79Capítulo 5. Os padrões de design de estratégia e comando
174Analisando as deficiências do padrão de design do decorador
80Diretriz 19: Use a estratégia para isolar como as coisas são feitas
175Diretriz 36: Compreenda a compensação entre tempo de execução e abstração de tempo de compilação
81Analisando os problemas de design
176Um decorador de tempo de compilação baseado em valor
82O padrão de design de estratégia explicado
177Um decorador de tempo de execução baseado em valor
83O padrão de design de estratégia
178Capítulo 10. O Padrão Singleton
84Analisando as deficiências da solução ingênua
179Diretriz 37: Trate Singleton como um padrão de implementação, não como um padrão de design: O Padrão Singleton Explicado
85Comparação entre visitante e estratégia
180O Padrão Singleton: Singleton não gerencia ou reduz dependências
86Analisando as deficiências do padrão de design de estratégia
181Diretriz 38: Projete Singletons para Mudança e Testabilidade
87Design Baseado em Políticas
182Singletons representam o estado global
88Diretriz 20: Favorecer a Composição sobre a Herança
183Singletons Impedem Mutabilidade e Testabilidade
89Diretriz 21: Use o comando para isolar o que as coisas são feitas: O padrão de design de comando explicado
184Invertendo as dependências em um singleton
90O padrão de design de comando
185Aplicando o padrão de design de estratégia
91O padrão de design de comando versus o padrão de design de estratégia
186Avançando em direção à injeção de dependência local
92Analisando as deficiências do padrão de design de comando
187Capítulo 11. A Última Diretriz
93Diretriz 22: Prefira a semântica de valor à semântica de referência
188Diretriz 39: Continue aprendendo sobre padrões de design
94As deficiências do estilo GoF: semântica de referência
189Colofão
95Semântica de referência: um segundo exemplo