Padrões de Implementação e Padrões de Projeto Estágio docência Adriano Francisco Ronszcka Professores Jean Marcelo Simão Hermes Irineu Del Monego Fundamentos.

Apresentação em tema: "Padrões de Implementação e Padrões de Projeto Estágio docência Adriano Francisco Ronszcka Professores Jean Marcelo Simão Hermes Irineu Del Monego Fundamentos."— Transcrição da apresentação:

1 Padrões de Implementação e Padrões de Projeto Estágio docência Adriano Francisco Ronszcka Professores Jean Marcelo Simão Hermes Irineu Del Monego Fundamentos de Programação 2

2 Adriano Francisco Ronszcka Bacharel em Sistema de Informação – UnC – Mafra/SC (2005-2009) Computação Evolucionária – Sistemas de Enxames – ACO Mestre em Ciência da Computação – Engenharia de Software – CPGEI – UTFPR (2010-2012) Engenharia de Software – Padrões de Implementação e Padrões de Projeto – Paradigma Orientado a Notificações Doutorando em Ciência da Computação - Engenharia de Software – CPGEI - UTFPR (2014 -...) Ciência da Computação – Linguagens de programação e compiladores – Paradigma Orientado a Notificações

3 Agenda Acoplamento e Coesão Sintomas de um projeto mal estruturado Princípios de Programação Padrões de Projeto Padrões de Implementação

4 Alto Acoplamento Forte dependência entre classes/objetos Dificuldade em alterar uma classe/objeto sem afetar o comportamento do sistema todo Dificuldade em adicionar novas funcionalidades ao sistema sem precisar alterar o código existente

5 Acoplamento

6 Baixa Coesão Várias funcionalidades em uma classe/objeto Difícil reaproveitamento Difícil manutenção Alta complexidade

7 Coesão

8 Fácil de entender Fácil de alterar Fácil de reusar Projeto de Qualidade

9 Rigidez: Difícil de alterar Uma alteração requer uma cascata de outras alterações Impacto das alterações não é previsível Fragilidade: A cada alteração novos erros aparecem em áreas aparentemente desconectadas. Imobilidade: Sem muita possibilidade de reuso. Partes desejadas de um componente possui muitas partes indesejadas para o reuso Sintomas de um projeto mal estruturado

10 Viscosidade: Alterações corretas são mais difíceis de fazer que as erradas Obscuro: Difícil de entender. Complexidade desnecessária. Repetição desnecessária. Sintomas de um projeto mal estruturado

11 No que isso implica? A presença desses sintomas indica que o software está mal estruturado, dificultando o aproveitamento das qualidades da Orientação a Objetos: Flexibilidade Reusabilidade Manutenibilidade

12 Boas práticas de programação A chave para a construção de bons programas está presente na antecipação de novos requisitos e mudanças para os já existentes...

13 Princípios de Programação - SOLID Single Responsibility Principle Open-Closed Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle

14 Single Responsibility Principle Cada classe/objeto deve possuir apenas uma razão para ser criada e/ou modificada. Responsabilidade = Razão para mudança Múltiplas responsabilidades = Alto acoplamento e Baixa coesão Se uma classe faz mais de uma coisa, separe em mais classes

15

16 Open-Closed Principle Cada classe deve estar aberta para extensão e fechada para modificação. Requisitos mudam (e como mudam!!!) Contemplar requisitos adicionando novo código e não alterando código existente! Se a alteração de uma classe resultar em uma cascata de alterações, o projeto está “ruim”

17 Open-Closed Principle Separe o que varia Encapsular o que varia para que não afete o resto do código Menos consequências indesejadas Mais flexibilidade Abstração e Polimorfismo são a chave para este princípio

18

19 Liskov Substitution Principle Classes derivadas devem ser capazes de substituir suas classes bases sem alterar abruptamente o comportamento esperado por elas. Violar o princípio LSP frequentemente resulta em checagem de tipo (ou casts explícitos) em tempo de execução

20

21 Interface Segregation Principle Classes não deveriam ser forçadas a depender de métodos que não usam e/ou implementam. Utilizar interfaces específicas ao invés de interfaces genéricas e “gordas” Interfaces grandes podem introduzir acoplamentos não desejados entre as classe

22 Interface Segregation Principle

23

24 Dependency Inversion Principle Módulos de software que encapsulam políticas de alto-nível (objetos centralizadores) não devem depender de módulos de software de baixo nível (objetos colaboradores). Ambos devem depender de abstrações. Ligar módulos por meio de abstrações e não por classes concretas Crie suas próprias interfaces para encapsular o comportamento de bibliotecas de terceiros

25 Padrões de Projeto

26 Observer

27

28

29 Singleton / Strategy

30 Model View Controller (MVC)

31

32

33 Padrões de Implementação Vocabulário compartilhado entre desenvolvedores Promovem melhor legibilidade Reduzem tempo de desenvolvimento e manutenção

34 Padrões de Implementação Escrever software é como qualquer outra escrita Os pensamentos devem ser rascunhados e refinados até a leitura se tornar agradável A leitura de um código-fonte deveria ser como a leitura de um livro: Capacidade de dizer o que está acontecendo numa primeira leitura A continuação da leitura deveria ser capaz de sanar quaisquer dúvidas

35 Padrões de Implementação Nomenclatura adequada dos elementos de software Todos os elementos do software são nomeados! Classes, instâncias de objetos, métodos, atributos... Nomear os elementos com seu significado: double d; // Distância em metros double distanceInMeters;

36 Padrões de Implementação Função coesa e autoexplicativa: double Speedometer::convertSpeedFromMPSToKPH(double speedInMPS) { return (speedInMPS * 3.6); } E quanto a utilização de comentários??? Depende... Se o código-fonte é legível o bastante, a utilização de comentários é desnecessária. Se o código está ruim de entender, arrume! Não comente...

37

38 Referências Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995. Brett D. McLaughlin, Gary Pollice e Dave West. Head First Object- Oriented Analysis and Design. O’REILLY, 2006. Robert Cecil Martin. Clean Code: A Handbook of Agile Software Craftsmanship. 1ed. Prentice-Hall, 2008. Adriano Francisco Ronszcka. Contribuição para a Concepção de Aplicações no Paradigma Orientado a Notificações (PON) sob o viés de padrões. Dissertação de mestrado. UTFPR, 2012.