OOP - Begins

Uma introdução sobre os princípios básicos de Orientação a Objetos.

Transcript

1. OOP Begins ...entenda os porquê.
2. …
3. O meu software está apodrecendo?
4. Como posso identificar isso?
5. Sintomas de APODRECIMENTO 1. Rigidêz 2. Fragilidade 3. Imobilidade 4. Viscosidade
6. Rigidêz é a tendência que um software tem de ser dificil de se fazer alterações.
7. Sintomas de Rigidêz • Alterações simples tornam-se investidas de semanas • Medo de corrigir problemas não críticos • Dificuldade de estimar prazos
8. Fragilidade acontece quando uma manutenção num pedaço isolado do software quebra o software em diversos lugares.
9. Sintomas de fragilidade • Quebra em locais sem vínculo algum de negócio • Toda manutenção o torna pior • O time tem receio de fazer o software parar de funcionar se mexer nele
10. Imobilidade é a incapacidade de se reusar software de outros projetos ou de parte do mesmo projeto.
11. Sintoma da imobilidade • O Desenvolvedor nota que poderia usar rotinas que estão em outro projeto • Ele nota que a rotina traz com ele muitas dependencias do outro projeto • Nota-se que o risco de trazer a rotina é muito alto • Reescreve-se a rotina
12. Viscosidade ocorre quando se investe muito tempo para resolver um problema e não se tem avanço.
13. Viscosidade por design ocorre quando é mais fácil fazer um Hack ( gambiarra ) do que manter o design original.
14. Viscosidade por ambiente ocorre quando o ambiente de desenvolvimento é lento ou ineficiente.
15. “Qualquer aplicação que apresente estes [ sintomas ] está apodrescendo de dentro para fora.” Robert C. Martin
16. Mas quais seriam as causas destes sintomas?
17. 1. Mudanças de requisitos As vezes nem sequer foi terminado de implementar o requisito, e ele já sofre mudança.
18. 2. Gestão de dependencias Para atingir às demandas é preciso alterar as dependencias dos módulos entre si, e nem sempre o design permite isso.
19. Fatos sobre o código 1. Quanto mais dependencias um código possui, mais estável ele é. 2. Regras voláteis são pontos de mudança no sistema ( fragilidade ). 3. Dependencias concretas indicam pontos de rigidêz. 4. Agrupamento de responsabilidades também indicam rigidêz e fragilidade do código.
20. A OOP fornece vários princípios e técnicas que permitem desenhar uma arquitetura tolerânte à mudanças. Por que, então, usar OOP?
21. Principios da OOP 1. Single Responsibility Principle 2. Open Closed Principle 3. Liskov Substituition Principle 4. Interface Segregation Principle 5. Dependency Inversion Principle
22. Single Responsibility Principle Uma classe deve ter uma, e apenas uma, razão para ser alterada.
23. Considerações sobre SRP 1. Resposabilidade - razão para mudar / alterar ( Modem Dilemma ) 2. Complexidade Desnecessária 3. O fator mudança deve ser considerado apenas se a mudança realmente acontecer ( volatilidade ).
24. Open closed Principle Um módulo deve ser fechado para modificações, mas aberto à extensões.
25. Técnicas aplicadas a OCP 1. Encapsulamento 2. Estratégia ( Strategy Pattern ) 3. Factories
26. Liskov Substituition Principle Referências à subclasses devem ser substituíveis ( e honrar o contrato definido ) pela sua classe base.
27. Interface Segregation Principle Você não deve ser obrigado a depender de uma interface que você não precisa. Muitas interfaces específicas são melhores que uma interface genérica.
28. Dependency Inversion Principle Dependa de métodos abstratos ao invés de implementações concretas de classes.
29. Considerações sobre DIP/ISP 1. Alterações nas interfaces quebram compatibilidade 2. Quebras geram retrabalho, recompilação e rebuild 3. Alguns engenheiros acabam escolhendo fazer um caminho alternativo ao invés de seguir o caminho tradicional.
30. Miere Teixeira email/hangout: miere.teixeira@texoit.com skype: miere.teixeira Muito Obrigado