# 99 Bottles of OOP - Chapter 3

### Bruno
- Otimização prematura;
- SOLID;
- Code Smell:
- Primitive Obsession;
- Duplicated Code;
- Giant/God Class;
- Simplificando problemas dificeis:
- Encontrar diferenças;
- Dar significado há elas;
- Testes;
- Refatoração;
- Flocking Rules;

## Johny

- Primeiramente, clarear os requerimentos, e então escrever o mínimo necessário de código
- Condicionais são o terror da OO
- Princípios SOLID (Robert "Uncle Bob" Martin):
- Single Responsibility - métodos em uma classe devem ser coesos em torno de um único propósito
- Open-Closed - objetos devem ser abertos para extenção, fechados para modificação
- Liskov Substitution - Subclasses devem ser substituíveis para suas superclasses
- Inteface Segregation - objetos não devem ser forçados a dependerem de métodos que não usam
- Dependency Inversion - dependa de abstrações, não concreções
- Quando encarar um novo requerimento, rearranjar o código existente para tornar aberto a nova feature. Uma vez completo, adicionar o novo código
- Se não souber como tornar aberto, remover o smell mais simples/fácil de entender (faça uma lista das coisas que você desgosta sobre o código)
- Flocking Rules:
- Selecione as coisas que são mais parecidas
- encontre a menor diferença entre elas
- faça a mudança mais simples que vai remover esta diferença
- O nome de algo deve ser um nível de abstração maior, não mais

## dalvi
- faz o minimo de codigo suficiente, soh mexe depois que alguem pedir
- open-closed
- code smells
- DRYing out difference has more value
- problemas dificeis podem ser assim apenas pq tem varios problemas faceis no meio que nao foram resolvidos
* quero ler o refactoring ruby version, mas custa 300 real

## Gabs
- make it open
- moving code around/refactoring vs. add new feature
- code smells
- refactor: improves internal structure but does not alter the external behavior
- making small changes
- look for differences

## Igor
- "The most cost-effective code is as good necessary, but no better."
- sOlid (Open/Closed)
- _aberto pra ser extendido, fechado pra modicações_
- Baby steps (again)
- "Quando der de cara com o requisito, primeiro arruma o código existente pra ele ficar aberto e poder receber a nova funcionalidade, uma vez que fez isso, aí sim pode adicionar o código novo"
- _flowchart_
.ta aberto? sim: faça a alteracao
.sabe como abrir? sim: abra-o. não: remova o code smell mais simples/facil de entender
- se não ta claro como abrir o codigo, comece removendo os _code smells_.
- _Refactoring_
."Alterar a organização do código sem mudar seu comportamento."
- _Flocking Rules_
- Abstração
- "Se o problema está resolvido, e você o refatora agora e não depois, você paga por não poder solucionar outros problemas."
- "Uma boa maneira de de saber se está usando o tempo de forma sábia é ser guiado pelas mudanças nos requisitos. A chegada de um novo requisito nos diz 2 coisas, uma bem específica e outra mais genérica."
- "Um código está aberto para um novo requisito quando o mesmo pode ser adicionado sem alterar o código já existente"
- "testes são o muro nas suas costas (te dão cobertura)"

### Conclusões
- Bom senso e parcimônia.
- Busquem conhecimento.
- Quando na refatoração, olhar também para as diferenças e não apenas para as semelhanças.
- "Quando der de cara com um novo requisito, primeiro prepare o código existente pra que ele fique extensível para receber a nova funcionalidade, uma vez feito isso podemos adicionar o código novo"