Paradigmas de Programação - Imperativo, Orientado a Objetos e Funcional

Aula sobre Paradigmas de Programação. São abordados: Paradigmas Imperativo, Paradigma Orientado a Objetos e Paradigma Funcional

1. Linguagens de
Programação
Aula 23 - Paradigmas de
Linguagens de Programação
Prof. Gustavo Coutinho

2. Programa da disciplina
1.Análise Sintática e Léxica ✓
2.Semântica Formal ✓
3.Verificação e inferência de tipos ✓
4.Teoria dos tipos ✓
5.Paradigmas de Linguagens de
Programação

3. Conteúdo Programático
▪Recapitulando...
▪Paradigma Imperativo
▪Paradigma Orientado a Objetos
▪Paradigma Funcional
▪Conclusão e Revisão
▪Exercícios!

4. Avisos
Informes gerais sobre a disciplina
0

5. Avisos
▪Página da disciplina atualizada (notas de
aula e descrição do trabalho final)!
▫http://ali.ifce.br/~gustavolgcr/lip
▪Enviar membros dos grupos para o
e-mail do professor
▫[email protected]
▫Grupos com 3 integrantes

6. Recapitulando...
Recapitulando a aula anterior...
1

7. Paradigmas de Linguagens
de Programação
▪Um paradigma é um padrão de
raciocínio para resolução de problemas!
▪A maioria das linguagens podem
suportar mais de um paradigma.
▪Cabe ao programador escolher o
paradigma mais adequado ao seu
problema.

8. Aula de hoje
Iremos abordar 3 dos paradigmas mais
populares:
▪Paradigma Imperativo;
▪Paradigma Orientado a Objetos;
▪Paradigma Funcional.

9. Paradigma
Imperativo
“Faça isso, depois isso, depois aquilo...”
2

10. ▪Na Segunda Guerra
Mundial, a máquina
ENIAC foi desenvolvida.
▪Custos de manutenção
e implementação eram
muito altos!
Motivação

11. Paradigma Imperativo
John von Neumann reconheceu que um
programa e suas variáveis podem residir
na memória principal de um computador.
▪Nasce a arquitetura de von Neumann!
O Paradigma Imperativo é criado para dar
suporte a essa nova arquitetura.

12. Programa
Variáveis
Entrada Saída
Controle
Aritmética
Lógica
Figura 1. O modelo computacional de John von Neumann.

13. Caracteristicas Principais:
Paradigma Imperativo
Com a evolução do paradigma, uma
linguagem imperativa suporta, dentre
outras, as seguintes características comuns.
1.Atribuições, Declarações e Expressões;
2.Estruturas de Controle;
3.Abstração Procedural

14. Atribuições, Declarações e
Expressões
No coração desse paradigma, temos a idéia
de atribuição.
▪Alterar o valor de um local da memória e
destruir o valor anterior.

15. Declaração de variável
▪Nome a um local de memória
▪Tipo a valores armazenados
Interpretar expressões
▪Recuperar valores em um determinado
endereço de memória
Atribuições, Declarações e
Expressões

16. ●Nome: x
●Tipo: Integer
●Valor: 5
●Posição: 89142
●Nome: z
●Tipo: Integer
●Valor: 1
●Posição: 569111
●Nome: y
●Tipo: Double
●Valor: 7.56
●Posição: 254896
Atribuição
●x = 5
●x = 17
Atribuições, Declarações e
Expressões
Memória

17. Estruturas de controle
Comandos são executados na sequência
em que aparecem na memória!
- Condicionais podem selecionar
caminhos alternativos durante a execução;
-Laços repetem blocos de códigos
utilizando testes ou iteradores como
controle.

18. Figura 2. Comandos sendo executados na sequência em que aparecem na memória.
Memória

19. Abstração Procedural
No início do desenvolvimento de linguagens
imperativas, o valor de funções reusáveis
foi reconhecido.
▪A abstração procedural permite o
programador preocupar-se somente com
a interface da função desejada.

20. Figura 3. Código de um programa em C para um algoritmo de ordenação.

21. Figura 4. Código de um programa em C para um algoritmo de ordenação com a função
implementada.

22. Recapitulando...
1
Baseado na arquitetura de
John von Neumann.

2
No coração desse
paradigma, temos a idéia
de atribuição.
3
Comandos executados na
ordem que aparecem na
memória.
4
Suporte a declaração de
variáveis, condicionais,
laços.
5
Suporte a abstração
procedural.
6
Linguagens Populares
C, Ada e Java

23. Paradigma
Orientado a
Objetos
“Uma viagem até Objetópolis…”
3

24. Motivação
Vamos considerar um sistema
implementado em uma linguagem
imperativa que utilize a validação de um
C.P.F. .

25. Motivação
▪C.P.F. será sempre
validado?
▪Qual programador vai
ficar responsável pela
verificação?
▪E se um novo
desenvolvedor entrar?
▪Precisamos conhecer o
código inteiro
internamente?
O problema do paradigma imperativo é que não existe uma
forma simples para criar uma conexão forte entre dados e
funcionalidades.

26. Paradigma Orientado a
Objetos
A P.O.O. trata os programas como uma
coleção de objetos que se comunicam
passando mensagens, dados.
▪Concentra as responsabilidades nos
lugares certos;
▪Flexibiliza a aplicação;
▪Encapsula a lógica de negócios.

27. Classes e objetos
Vamos imaginar um sistema bancário.
▪A entidade principal desse sistema será a
CONTA bancária!
Como generalizar as informações e
funcionalidades de uma conta?

28. Classes e objetos
Informações
▪Número da conta
▪Nome do titular
▪Saldo
▪Limite
Atributos
Funcionalidades
▪Sacar valor
▪Depositar valor
▪Transferir valor
▪Imprimir saldo
Métodos

29. Conta
Número : 852369
Cliente: Ludmila
Saldo : R$1500,00
Limite : R$100,00
Número : 741582
Cliente: Fernanda
Saldo : R$2500,00
Limite : R$200,00
Número : 564897
Cliente: Gilberto
Saldo : R$1000,00
Limite : R$150,00
Figura 5. Projeto de uma conta bancária.

30. Conta
Número : 852369
Cliente: Ludmila
Saldo : R$1500,00
Limite : R$100,00
Número : 741582
Cliente: Fernanda
Saldo : R$2500,00
Limite : R$200,00
Número : 564897
Cliente: Gilberto
Saldo : R$1000,00
Limite : R$150,00
CLASSE OBJETO
Figura 6. Classe conta e alguns objetos.

31. Visibilidade e Ocultamento
de Informação
Problema inicial
▪O que aconteceria se nosso sistema
tentasse fazer um saque de um valor
que ultrapasse o valor do saldo?
▫Inconsistência no sistema!
▪Como resolver?

32. Figura 7. Classe Conta e Classe TestaContaEstouro com inconsistência no sistema

33. Figura 7. Classe Conta e Classe TestaContaEstouro com inconsistência no sistema

34. Figura 7. Classe Conta e Classe TestaContaEstouro com inconsistência no sistema

35. Figura 7. Classe Conta e Classe TestaContaEstouro com inconsistência no sistema

36. Visibilidade e Ocultamento
de Informação
A validação não deve ser controlada por
quem utiliza a classe, mas sim por ela
mesma.
Para controlar a visibilidade de métodos e
atributos, utilizamos modificadores de
acesso.

Concentrar
responsabilidades!

37. Visibilidade e Ocultamento
de Informação
Existem 3 níveis principais de visibilidade
(modificadores de acesso) entre classes e
subclasses:
▪public: visível a todos,
▪protected: visível a subclasses,
▪private: visível a própria classe.
Encapsula a Lógica
de Negócios!

38. Visibilidade e Ocultamento
de Informação
Existem 3 níveis principais de visibilidade
(modificadores de acesso) entre classes e
subclasses:
private
protected
public

39. Herança
Outra entidade muito importante do nosso
sistema bancário são os Funcionários.

E se quisermos modelar, em seguida, um
Gerente? E um Diretor? Um Secretário?

40. Figura 8. Modelagem da Classe Funcionario e da Classe Gerente.
Poderíamos incluir as
informações de Gerente
em Funcionario?

Poderíamos...

41. Figura 9. Modelagem da Classe Funcionario e da Classe Gerente.

42. Para solucionar esse
problema, a Orientação a
Objetos nos provê o conceito
de Herança!

A classe filha vai herdar
todos os atributos e métodos
da classe mãe.
Herança
Funcionário
Gerente
Superclasse
Subclasse
Diretor Secretário
Subclasse Subclasse
Flexibilizar
Aplicação!

43. Polimorfismo
O que guarda uma variável do tipo
Funcionário?
▪Referência para um Funcionário.
Podemos nos referir a um Gerente como
um Funcionário.
▪Gerente É-UM Funcionário

44. Polimorfismo
double
getBonificação()
Polimorfismo é a capacidade de um objeto
poder ser referenciado de várias formas!

Funcionario
Secretário Gerente
É-UM É-UM
double
getBonificação()

45. Interfaces
Imagine um Sistema
Interno que autentica
Gerente e Diretor.

Funcionario
Secretário Gerente
É-UM É-UM
Diretor
É-UM
Sistema Interno
Autentica
Autentica

46. Figura 10. Métodos de autentica() das classes Gerente e Funcionário.

47. Sistema Interno tem o
seguinte método:
Interfaces
Funcionario
Secretário Gerente
É-UM É-UM
Diretor
É-UM
Sistema Interno
Autentica
Autentica

48. Interfaces
Sistema Interno tem o
seguinte método:Funcionario
Secretário
GerenteDiretor
Sistema Interno
Funcionario
Autenticável
É-UM
É-UM
É-UM É-UM

49. Interfaces
Sistema Interno tem o
seguinte método:Funcionario
Secretário
GerenteDiretor
Sistema Interno
Funcionario
Autenticável
É-UM
É-UM
É-UM
Cliente
É-UM

50. Interfaces
Qual o fator comum entre Diretor, Cliente e
Gerente? O método Autentica!
Precisamos de um contrato:
contrato Autenticavel:
quem quiser ser Autenticavel, precisa saber fazer:
▪autenticar dada uma senha, devolvendo um
booleano

51. Interfaces
Funcionario
Secretário
É-UM É-UM
Diretor
É-UM
Sistema Interno
Autentica
Autentica
Autenticável
Cliente
Gerente

52. Recapitulando...
1
P.O.O. trata os programas
como uma coleção de
objetos que se
comunicam passando
mensagens.
2
No coração desse
paradigma, temos o
conceito de classes e suas
instâncias, os objetos.
3
Classes são compostas por
informações, chamadas de
atributos, e
funcionalidades,
chamadas de métodos.
4
Atributos e métodos
podem ter diferentes
visibilidades com relação
a outras classes.
5
P.O.O. oferece conceitos
de herança,
polimorfismo e
interfaces.
6
Linguagens Populares
C++, Java e Python

53. Paradigma
Funcional
“Sometimes, the elegant
implementation is just a function…”
4

54. Paradigma Funcional
Motivada pela necessidade de
pesquisadores no desenvolvimento de I.A.
▪John McCarthy criou a linguagem Lisp
Computação é vista como uma função
matemática mapeando entradas a saídas.
▪Não existe a noção de estado!

55. Em Programação Funcional, variáveis não
variam! Veja os seguintes códigos:
Primeiros passos com
Programação Funcional
Figura 11. Exemplo de variáveis no Paradigma Imperativo (esq.) e Funcional (dir).

56. Paradigma Funcional
Veremos algumas aspectos importantes
do Paradigma Funcional.
1.Expressões Lambda;
2.Funções e Listas;
3.Recursões;
4.Funções Preguiçosas.

57. Expressões Lambda (λ)
Expressão Lambda é a base do Paradigma
Funcional.
▪Especifica os parâmetros e a definição de
uma função, mas não seu nome.
Exemplo:
(λx⋅x*x) → ((λx⋅x*x)2) → 4

58. Funções e Listas
No coração desse paradigma, temos as
funções. Mas como utilizá-las?
Usaremos a linguagem Clojure como
exemplo.
▪Dialeto da linguagem LISP,
▪Executada na Máquina Virtual Java (JVM).

59. Figura 12. Funções para imprimir na tela e contar até zero.
Funções e Listas

60. Uma função de ordem superior é uma
função que recebe funções como
parâmetros ou que leva a função como
resultado, ou ambos.

Exemplo: Função map
Funções e Listas

61. A função map recebe uma outra função que
é aplicada a uma lista de números.
Funções e Listas

62. Funções recursivas e
recursão de cauda
O uso de recursões para especificar
repetições pode deixar programas muito
lentos!
Podemos sofrer com o empilhamento das
funções.

63. Funções recursivas e
recursão de cauda
fib(5)
fib(4)
fib(3)
fib(2)
fib(1)
Ramo da árvore de
execução
Figura 13. Exemplo de função recursiva.

64. Funções recursivas e
recursão de cauda
Recursão em cauda pode solucionar o
problema.
Se uma chamada recursiva em uma função
é a última expressão na função, um
compilador pode facilmente converter tal
recursão em uma iteração.

65. Funções recursivas e
recursão de cauda
Figura 14. Utilizando recursão em cauda na função de Fibonacci.

66. +=loop 1 2 3
loop 2 3 4
loop 3 5 5
fib(3) fib(2) fib(2) fib(1)
fib(2) fib(1)
fib(5) fib(4) fib(3)
COM cauda SEM cauda
Figura 14. Comparação entre a recursão COM cauda e SEM cauda.
fib(5)

67. Funções preguiçosas
Em linguagens funcionais, existe o conceito
de função preguiçosa, a qual não é
executada até ser pedido seu resultado.
Permite a definição de estruturas de dados
infinitas.

68. Funções preguiçosas
Figura 16. Exemplo de função preguiçosa.

69. Recapitulando...
1
Computação é vista como
uma função matemática.
A noção de estado não
existe!
2
Expressões Lambda é a
base do Paradigma
Funcional!
3
Funções são o coração do
paradigma, permitindo
inclusive iterações através
de recursão.
4
Funções de ordem
superior podem receber e
retornar outras funções.
5
Recursão em cauda tenta
resolver o problema do
empilhamento excessivo.
6
Linguagens Populares
Clojure, Scala e Java

70. Revisão e
Conclusão
"Se liga aí, que é hora da revisão!"
5

71. Revisão
Paradigmas de Program.
▪Padrão de raciocínio
para resolver problemas;
▪Linguagens geralmente
suportam mais de um
paradigma.
Paradigma Imperativo
▪Baseado na arquitetura
de John von Neumann;
▪No coração desse
paradigma, temos as
atribuições.

72. Revisão
Paradigma Orien. a Obj.
▪Trata programas como
uma coleção de objetos;
▪Conceitos fundamentais:
classes e objetos.
Paradigma Funcional
▪Variáveis não variam;
▪Computações são vistas
como uma função;
▪Não existe a noção de
estado!

73. Conclusão
▪Na aula de hoje, continuamos o estudo
de Paradigmas de Programação.
▪Os alunos devem entender bem os
conceitos básicos dos principais
paradigmas.
▪Dessa forma, a migração para uma nova
linguagem será mais suave.

74. Próxima aula
1.Paradigma Lógico;
2.Paradigma Concorrente;
3.Paradigma Orientado a Eventos;
4.Orientações sobre o trabalho final.

75. Exercícios
Praticando conceitos
6

76. Exercícios
▪Iniciaremos a lista de exercícios em sala
de aula, agora.
▪As questões que não forem resolvidas
deverão ser entregues na próxima aula.
▪Iniciaremos o próximo encontro com
dúvidas sobre os exercícios.

77. Bibliografia
[BÁSICA]
●TUCKER, A.; NOONAN, R. Linguagens de Programação: Princípios e Paradigmas. [S.I.]: AMGH
Editora, 2009.
●SEBESTA, R. W. Conceitos de linguagens de programação. [S.I.]: Bookman Editora, 2009.

[COMPLEMENTAR]
●WATT, D. A. Programming language design concepts. [S.I.]: John Wiley e Sons, 2004.
●VAN-ROY, P.; HARIDI, S. Concepts, techniques, and models of computer programming. [S.I.]: MIT
press, 2004.

78. OBRIGADO!
Dúvidas?
[email protected]