SlideShare uma empresa Scribd logo
R O D R I G O V I E I R A P I N T O
2 0 1 6
ASPECTOS DO APRENDIZADO DO
PARADIGMA ORIENTADO A OBJETOS POR
PROGRAMADORES PROCEDIMENTAIS
1
AGENDA
• Quem sou eu?
• Dificuldades no desenvolvimento de sistemas
• Por que algumas dessas dificuldades ocorrem
• Exemplo – sistema de estacionamento
• Pequena história da orientação a objetos
• Comparações entre sistemas
• De volta ao sistema de estacionamento
• Considerações finais
• Perguntas e comentários
2
QUEM SOU EU?
• Bacharel em Ciência da Computação pela USJT
• Pós-graduado em Engenharia de Software pela PUC-SP
• Trabalho há 13 anos com desenvolvimento de sistemas
em Java, Ruby, PHP, C
• Mestrando em Engenharia de
Software pelo IPT-SP
• Técnico em mecânica pela
ETE José Rocha Mendes e
Mecânico Geral pelo SENAI-SP
• Amante de software bem
escrito 
3
O QUE VI?
• Informática é uma ciência muito mais recente que a
mecânica. Daí possuir um nível de maturidade mais
baixo
• Código escrito para resolver um problema…
…do programador, não do sistema
4
O QUE JÁ FOI VISTO
• 60 milhões de dólares anuais (EUA) em prejuízos!
• Alguns dos erros mais famosos da história do
desenvolvimento de sistemas
5
O QUE JÁ FOI VISTO
• Bug do milênio: 500 bilhões de dólares
• Terceira Guerra Mundial: quase toda a humanidade
6
O QUE JÁ FOI VISTO
• Os prejuízos não são por causa tão somente de erros
nos sistemas
• São também causados por software mal escrito
• Altos custos de manutenção
7
POR QUE?
• Há diversos motivos, mas podemos citar:
• falta de conhecimento das ferramentas/frameworks utilizados;
• falta de conhecimento do paradigma que a linguagem suporta;
• a dificuldade de aprendizado do paradigma OO;
• a “semelhança” entre os paradigmas procedimental e OO;
8
POR QUE?
- o fato de se conhecer o paradigma procedimental (interferência
proativa)
9
EXEMPLO
10
• Muitos programadores programam em Java dessa
forma.
• Possuem background em linguagens procedurais
• Se for escrito em uma linguagem procedural, pouca
coisa vai mudar!
• O sistema funciona!
• Mas o que tem de errado? São classes, não são?
11
ANTES, UM POUCO DE HISTÓRIA
• Orientação a objetos:
• Primeiros passos na década de 60, com a criação da linguagem
SIMULA (depois SIMULA 67) criada por Krysten Nygaard e Ole-
Johan Dahl
• A orientação a objetos como conhecemos hoje surge com a
linguagem Smalltalk, criada por Alan Kay
12
ANTES, UM POUCO DE HISTÓRIA
• O propósito inicial da orientação a objetos foi simular
comportamentos (inclusive humanos) num computador
• Verificou-se que dessa forma:
• Os dados ficavam mais próximos dos processadores de dados
(procedimentos), facilitando a manutenção;
• O código pode ser organizado de acordo com o negócio que ele
pretende resolver
13
ANTES, UM POUCO DE HISTÓRIA
14
TRANSIÇÃO ENTRE OS PARADIGMAS
• Ao pensar de maneira estruturada, nós enxergamos o
problema a ser resolvido como um conjunto de
estruturas de dados que são manipuladas por funções.
• Para modelarmos da maneira orientada a objetos,
devemos pensar em entidades que possuem estados e
comportamentos!
15
TRANSIÇÃO ENTRE OS PARADIGMAS
• Abordagem revolucionária, ao invés de evolucionária
• Os tratados mais antigos ensinavam a pensar em
objetos como um “exército de pequenos robôs virtuais”
para resolver um problema
• Atualmente, as escolas de pensamento defendem que
sejam criados objetos para modelar um modelo de
domínio
16
TRANSIÇÃO ENTRE OS PARADIGMAS
• O código fica mais distante da tecnologia que se utiliza,
e mais próxima do modelo de negócio que o sistema se
propõe a resolver, reduzindo o tempo de manutenção
17
(MAL) EXEMPLO – SISTEMA A
• Sistema na empresa onde trabalho atualmente
• +500000 linhas de código
• Alto volume de transações
• Lida com praticamente todos os setores da empresa
• Escrito em Java
18
(MAL) EXEMPLO
• Conhecido como o grande causador de dores de cabeça
da empresa. Há 4 anos.
• Escrito de forma procedural (classes usadas como
registros e classes de negócio, muito semelhante ao
nosso exemplo)
• Famoso por “correções em pequenos trechos
quebrarem trechos inimagináveis”
19
(BOM) EXEMPLO – SISTEMA B
• Sistema tido como o mais importante da empresa (é por
onde o dinheiro entra)
• 50+ transações por segundo nos horários de pico
• Problemas semelhantes ao Sistema A
20
(BOM) EXEMPLO – SISTEMA B
• Totalmente estruturado para permitir que outros clientes
possam utilizá-lo, usando orientação a objetos e modelo
de domínio
• Antes: quase 1 mes para permitir a entrada de outros
clientes
• Atualmente: no máximo 1 semana
• Ganho de entendimento: os desenvolvedores têm no
código algo muito próximo de uma documentação do
sistema. Compilável!
• …”há anos sem problemas em produção. Um sistema
que ninguém mais se preocupa tanto...”
21
VOLTANDO AO EXEMPLO
22
VOLTANDO AO EXEMPLO
• Esse modelo se parece com o mundo real?
• O motorista ou o manobrista vai pegar o carro e dirigi-lo
ate a vaga certa. O carro "sabe" estacionar, e essa é
uma responsabilidade dele: dada uma vaga, estacione.
• Vamos ver uma maneira de refatorar esse código:
23
VOLTANDO AO EXEMPLO
24
VOLTANDO AO EXEMPLO
• As classes possuem responsabilidades claras
• O código pode ter ficado maior, mas organizado
conforme os conceitos do domínio
• Como o que mais muda num sistema é o domínio e não
a tecnologia, é importante que ele reflita o negócio.
Dessa forma, todos (desenvolvedores e especialistas)
falarão a mesma língua.
25
• Não é possível escrevermos código procedimental com
termos do domínio?
• Sim, é possível. O problema é que o paradigma
procedimental não apoia o baixo hiato representacional
entre o negócio e o código, coisa que a orientação a
objetos faz muito bem.
26
UMA ÚLTIMA PALAVRA
• Objetos não são atributos + funções
• Mas são estados + comportamento
• Métodos não são funções, e vice-versa!
• Não crie métodos faz-tudo no seus sistemas, mas
objetos que colaborem entre si
27
ALAN KAY
"Uma vez que você encapsulou de tal forma que existe uma
interface entre o interior e o exterior, é possível fazer com que
um objeto aja como qualquer coisa, e a razão é simplesmente
esta: o que você encapsulou é um computador. Portanto, você
fez algo poderoso na ciência da computação, que é pegar o que
você transformou em poderoso sem perdê-lo particionando seu
“design space”. Isto é um bug em dados procedurais, dados e
linguagens procedurais. Acho que isto é a coisa mais perniciosa
em linguagens como C++ e Java. Estas acham que estão
ajudando o programador tentando se parecer o máximo possível
com o “antigo”, mas na verdade, estão ferindo o programador
terrivelmente tornando difícil para o programador entender o que
realmente é poderoso sobre esta nova metáfora."
28
REFERÊNCIAS
• KAY, A. The real computer revolution hasn’t happened yet. Viewpoints
Research Institute, v. 15, 2007.
• BOOCH, G. et al. Object-Oriented Systems Analysis and Design With
Applications. 3. ed. Massachusetts: Addison-Wesley, 2007.
• EVANS, E. Domain Driven Design - Atacando as Complexidades no
Coração do Software. 1. ed. Rio de Janeiro: Alta Books, 2009.
• LARMAN, C. Utilizando UML e Padrões. São Paulo: Bookman Editora, 2002.
• NELSON, H. J.; ARMSTRONG, D. J.; GHODS, M. Old Dogs and New Tricks.
Commun. ACM, v. 45, n. 10, p. 132–137, out. 2002.
• NELSON, H. J.; ARMSTRONG, D. J.; NELSON, K. M. Patterns of Transition:
The Shift from Traditional to Object-Oriented Development. Journal of
Management Information Systems, p. 271–298, 2009.
• OWE, O.; KROGDAHL, S. A Biography of Ole-Johan Dahl. p. 1–7, 2004.
• https://web.archive.org/web/20110401013847/http://fragmental.com.br/wiki/inde
x.php?title=Fantoches
• https://www.profissionaisti.com.br/2012/01/alguns-dos-mais-famosos-erros-de-
softwares-da-historia/
29
Obrigado!
Contatos:
rodrigovieirapinto@gmail.com
br.linkedin.com/in/rodrigovp
30

Mais conteúdo relacionado

Semelhante a Aspectos do aprendizado do paradigma orientado a objetos por programadores procedimentais

Clean Architecture
Clean ArchitectureClean Architecture
Clean Architecture
Rodrigo Branas
 
Uma perspectiva histórica e o cenário atual das ferramentas de desenvolviment...
Uma perspectiva histórica e o cenário atual das ferramentas de desenvolviment...Uma perspectiva histórica e o cenário atual das ferramentas de desenvolviment...
Uma perspectiva histórica e o cenário atual das ferramentas de desenvolviment...
Mario Guedes
 
Carreira de Desenvolvimento
Carreira de DesenvolvimentoCarreira de Desenvolvimento
Carreira de Desenvolvimento
Alvaro Viebrantz
 
Clean code @rogeriofontes-techfriday-everis
Clean code @rogeriofontes-techfriday-everisClean code @rogeriofontes-techfriday-everis
Clean code @rogeriofontes-techfriday-everis
Rogerio Fontes
 
Encontrando equilíbrio do DDD enquanto sua aplicação cresce
Encontrando equilíbrio do DDD enquanto sua aplicação cresceEncontrando equilíbrio do DDD enquanto sua aplicação cresce
Encontrando equilíbrio do DDD enquanto sua aplicação cresce
Carolina Karklis
 
Design Patterns - Com Java
Design Patterns  - Com JavaDesign Patterns  - Com Java
Design Patterns - Com Java
Felipe Do Nascimento
 
E xtreme programming
E xtreme programmingE xtreme programming
E xtreme programming
Kyllder Medeiros
 
Arquitetura de Software e o DNAD2013
Arquitetura de Software e o DNAD2013Arquitetura de Software e o DNAD2013
Arquitetura de Software e o DNAD2013
André Borgonovo
 
Padrões Web & Code Standard
Padrões Web & Code StandardPadrões Web & Code Standard
Padrões Web & Code Standard
Toni Albuquerque
 
Extreme Experience 2018 | Estudo de Caso: Aplicação DataSnap para 10.000 usuá...
Extreme Experience 2018 | Estudo de Caso: Aplicação DataSnap para 10.000 usuá...Extreme Experience 2018 | Estudo de Caso: Aplicação DataSnap para 10.000 usuá...
Extreme Experience 2018 | Estudo de Caso: Aplicação DataSnap para 10.000 usuá...
Mario Guedes
 
Introdução a arquitetura de sistemas com .NET
Introdução a arquitetura de sistemas com .NETIntrodução a arquitetura de sistemas com .NET
Introdução a arquitetura de sistemas com .NET
Mário Meyrelles
 
Aula1.pdf
Aula1.pdfAula1.pdf
Programação orientada à objetos & mvc
Programação orientada à objetos & mvcProgramação orientada à objetos & mvc
Programação orientada à objetos & mvc
Jhordam Siqueira
 
Sistemas para o Mundo Real - TDC 2012
Sistemas para o Mundo Real - TDC 2012Sistemas para o Mundo Real - TDC 2012
Sistemas para o Mundo Real - TDC 2012
Leandro Silva
 
Net uma revisão sobre a programação orientada a objetos
Net   uma revisão sobre a programação orientada a objetosNet   uma revisão sobre a programação orientada a objetos
Net uma revisão sobre a programação orientada a objetos
LP Maquinas
 
Aula 1 - Interaction Design From Ethnography, Mental Models to IA
Aula 1 - Interaction Design From Ethnography, Mental Models to IAAula 1 - Interaction Design From Ethnography, Mental Models to IA
Aula 1 - Interaction Design From Ethnography, Mental Models to IA
Amyris Fernandez
 
Introdução ao XP
Introdução ao XPIntrodução ao XP
Introdução ao XP
Paulo Rebelo, MSc, PMP, CSP
 
Interação Humano Computador Plataforma Mobile - Wellington Pinto de Oliveira
Interação Humano Computador Plataforma Mobile - Wellington Pinto de OliveiraInteração Humano Computador Plataforma Mobile - Wellington Pinto de Oliveira
Interação Humano Computador Plataforma Mobile - Wellington Pinto de Oliveira
Wellington Oliveira
 
Seminários V - Ads -UNOPAR ARAGUAINA,TO - POLO II
Seminários V - Ads -UNOPAR ARAGUAINA,TO - POLO IISeminários V - Ads -UNOPAR ARAGUAINA,TO - POLO II
Seminários V - Ads -UNOPAR ARAGUAINA,TO - POLO II
Dheimyson Carlos Sousa Silva
 
Programação Orientada a Objetos - Pós Graduação - aula 1
Programação Orientada a Objetos - Pós Graduação - aula 1Programação Orientada a Objetos - Pós Graduação - aula 1
Programação Orientada a Objetos - Pós Graduação - aula 1
Carlos Eduardo
 

Semelhante a Aspectos do aprendizado do paradigma orientado a objetos por programadores procedimentais (20)

Clean Architecture
Clean ArchitectureClean Architecture
Clean Architecture
 
Uma perspectiva histórica e o cenário atual das ferramentas de desenvolviment...
Uma perspectiva histórica e o cenário atual das ferramentas de desenvolviment...Uma perspectiva histórica e o cenário atual das ferramentas de desenvolviment...
Uma perspectiva histórica e o cenário atual das ferramentas de desenvolviment...
 
Carreira de Desenvolvimento
Carreira de DesenvolvimentoCarreira de Desenvolvimento
Carreira de Desenvolvimento
 
Clean code @rogeriofontes-techfriday-everis
Clean code @rogeriofontes-techfriday-everisClean code @rogeriofontes-techfriday-everis
Clean code @rogeriofontes-techfriday-everis
 
Encontrando equilíbrio do DDD enquanto sua aplicação cresce
Encontrando equilíbrio do DDD enquanto sua aplicação cresceEncontrando equilíbrio do DDD enquanto sua aplicação cresce
Encontrando equilíbrio do DDD enquanto sua aplicação cresce
 
Design Patterns - Com Java
Design Patterns  - Com JavaDesign Patterns  - Com Java
Design Patterns - Com Java
 
E xtreme programming
E xtreme programmingE xtreme programming
E xtreme programming
 
Arquitetura de Software e o DNAD2013
Arquitetura de Software e o DNAD2013Arquitetura de Software e o DNAD2013
Arquitetura de Software e o DNAD2013
 
Padrões Web & Code Standard
Padrões Web & Code StandardPadrões Web & Code Standard
Padrões Web & Code Standard
 
Extreme Experience 2018 | Estudo de Caso: Aplicação DataSnap para 10.000 usuá...
Extreme Experience 2018 | Estudo de Caso: Aplicação DataSnap para 10.000 usuá...Extreme Experience 2018 | Estudo de Caso: Aplicação DataSnap para 10.000 usuá...
Extreme Experience 2018 | Estudo de Caso: Aplicação DataSnap para 10.000 usuá...
 
Introdução a arquitetura de sistemas com .NET
Introdução a arquitetura de sistemas com .NETIntrodução a arquitetura de sistemas com .NET
Introdução a arquitetura de sistemas com .NET
 
Aula1.pdf
Aula1.pdfAula1.pdf
Aula1.pdf
 
Programação orientada à objetos & mvc
Programação orientada à objetos & mvcProgramação orientada à objetos & mvc
Programação orientada à objetos & mvc
 
Sistemas para o Mundo Real - TDC 2012
Sistemas para o Mundo Real - TDC 2012Sistemas para o Mundo Real - TDC 2012
Sistemas para o Mundo Real - TDC 2012
 
Net uma revisão sobre a programação orientada a objetos
Net   uma revisão sobre a programação orientada a objetosNet   uma revisão sobre a programação orientada a objetos
Net uma revisão sobre a programação orientada a objetos
 
Aula 1 - Interaction Design From Ethnography, Mental Models to IA
Aula 1 - Interaction Design From Ethnography, Mental Models to IAAula 1 - Interaction Design From Ethnography, Mental Models to IA
Aula 1 - Interaction Design From Ethnography, Mental Models to IA
 
Introdução ao XP
Introdução ao XPIntrodução ao XP
Introdução ao XP
 
Interação Humano Computador Plataforma Mobile - Wellington Pinto de Oliveira
Interação Humano Computador Plataforma Mobile - Wellington Pinto de OliveiraInteração Humano Computador Plataforma Mobile - Wellington Pinto de Oliveira
Interação Humano Computador Plataforma Mobile - Wellington Pinto de Oliveira
 
Seminários V - Ads -UNOPAR ARAGUAINA,TO - POLO II
Seminários V - Ads -UNOPAR ARAGUAINA,TO - POLO IISeminários V - Ads -UNOPAR ARAGUAINA,TO - POLO II
Seminários V - Ads -UNOPAR ARAGUAINA,TO - POLO II
 
Programação Orientada a Objetos - Pós Graduação - aula 1
Programação Orientada a Objetos - Pós Graduação - aula 1Programação Orientada a Objetos - Pós Graduação - aula 1
Programação Orientada a Objetos - Pós Graduação - aula 1
 

Aspectos do aprendizado do paradigma orientado a objetos por programadores procedimentais

  • 1. R O D R I G O V I E I R A P I N T O 2 0 1 6 ASPECTOS DO APRENDIZADO DO PARADIGMA ORIENTADO A OBJETOS POR PROGRAMADORES PROCEDIMENTAIS 1
  • 2. AGENDA • Quem sou eu? • Dificuldades no desenvolvimento de sistemas • Por que algumas dessas dificuldades ocorrem • Exemplo – sistema de estacionamento • Pequena história da orientação a objetos • Comparações entre sistemas • De volta ao sistema de estacionamento • Considerações finais • Perguntas e comentários 2
  • 3. QUEM SOU EU? • Bacharel em Ciência da Computação pela USJT • Pós-graduado em Engenharia de Software pela PUC-SP • Trabalho há 13 anos com desenvolvimento de sistemas em Java, Ruby, PHP, C • Mestrando em Engenharia de Software pelo IPT-SP • Técnico em mecânica pela ETE José Rocha Mendes e Mecânico Geral pelo SENAI-SP • Amante de software bem escrito  3
  • 4. O QUE VI? • Informática é uma ciência muito mais recente que a mecânica. Daí possuir um nível de maturidade mais baixo • Código escrito para resolver um problema… …do programador, não do sistema 4
  • 5. O QUE JÁ FOI VISTO • 60 milhões de dólares anuais (EUA) em prejuízos! • Alguns dos erros mais famosos da história do desenvolvimento de sistemas 5
  • 6. O QUE JÁ FOI VISTO • Bug do milênio: 500 bilhões de dólares • Terceira Guerra Mundial: quase toda a humanidade 6
  • 7. O QUE JÁ FOI VISTO • Os prejuízos não são por causa tão somente de erros nos sistemas • São também causados por software mal escrito • Altos custos de manutenção 7
  • 8. POR QUE? • Há diversos motivos, mas podemos citar: • falta de conhecimento das ferramentas/frameworks utilizados; • falta de conhecimento do paradigma que a linguagem suporta; • a dificuldade de aprendizado do paradigma OO; • a “semelhança” entre os paradigmas procedimental e OO; 8
  • 9. POR QUE? - o fato de se conhecer o paradigma procedimental (interferência proativa) 9
  • 11. • Muitos programadores programam em Java dessa forma. • Possuem background em linguagens procedurais • Se for escrito em uma linguagem procedural, pouca coisa vai mudar! • O sistema funciona! • Mas o que tem de errado? São classes, não são? 11
  • 12. ANTES, UM POUCO DE HISTÓRIA • Orientação a objetos: • Primeiros passos na década de 60, com a criação da linguagem SIMULA (depois SIMULA 67) criada por Krysten Nygaard e Ole- Johan Dahl • A orientação a objetos como conhecemos hoje surge com a linguagem Smalltalk, criada por Alan Kay 12
  • 13. ANTES, UM POUCO DE HISTÓRIA • O propósito inicial da orientação a objetos foi simular comportamentos (inclusive humanos) num computador • Verificou-se que dessa forma: • Os dados ficavam mais próximos dos processadores de dados (procedimentos), facilitando a manutenção; • O código pode ser organizado de acordo com o negócio que ele pretende resolver 13
  • 14. ANTES, UM POUCO DE HISTÓRIA 14
  • 15. TRANSIÇÃO ENTRE OS PARADIGMAS • Ao pensar de maneira estruturada, nós enxergamos o problema a ser resolvido como um conjunto de estruturas de dados que são manipuladas por funções. • Para modelarmos da maneira orientada a objetos, devemos pensar em entidades que possuem estados e comportamentos! 15
  • 16. TRANSIÇÃO ENTRE OS PARADIGMAS • Abordagem revolucionária, ao invés de evolucionária • Os tratados mais antigos ensinavam a pensar em objetos como um “exército de pequenos robôs virtuais” para resolver um problema • Atualmente, as escolas de pensamento defendem que sejam criados objetos para modelar um modelo de domínio 16
  • 17. TRANSIÇÃO ENTRE OS PARADIGMAS • O código fica mais distante da tecnologia que se utiliza, e mais próxima do modelo de negócio que o sistema se propõe a resolver, reduzindo o tempo de manutenção 17
  • 18. (MAL) EXEMPLO – SISTEMA A • Sistema na empresa onde trabalho atualmente • +500000 linhas de código • Alto volume de transações • Lida com praticamente todos os setores da empresa • Escrito em Java 18
  • 19. (MAL) EXEMPLO • Conhecido como o grande causador de dores de cabeça da empresa. Há 4 anos. • Escrito de forma procedural (classes usadas como registros e classes de negócio, muito semelhante ao nosso exemplo) • Famoso por “correções em pequenos trechos quebrarem trechos inimagináveis” 19
  • 20. (BOM) EXEMPLO – SISTEMA B • Sistema tido como o mais importante da empresa (é por onde o dinheiro entra) • 50+ transações por segundo nos horários de pico • Problemas semelhantes ao Sistema A 20
  • 21. (BOM) EXEMPLO – SISTEMA B • Totalmente estruturado para permitir que outros clientes possam utilizá-lo, usando orientação a objetos e modelo de domínio • Antes: quase 1 mes para permitir a entrada de outros clientes • Atualmente: no máximo 1 semana • Ganho de entendimento: os desenvolvedores têm no código algo muito próximo de uma documentação do sistema. Compilável! • …”há anos sem problemas em produção. Um sistema que ninguém mais se preocupa tanto...” 21
  • 23. VOLTANDO AO EXEMPLO • Esse modelo se parece com o mundo real? • O motorista ou o manobrista vai pegar o carro e dirigi-lo ate a vaga certa. O carro "sabe" estacionar, e essa é uma responsabilidade dele: dada uma vaga, estacione. • Vamos ver uma maneira de refatorar esse código: 23
  • 25. VOLTANDO AO EXEMPLO • As classes possuem responsabilidades claras • O código pode ter ficado maior, mas organizado conforme os conceitos do domínio • Como o que mais muda num sistema é o domínio e não a tecnologia, é importante que ele reflita o negócio. Dessa forma, todos (desenvolvedores e especialistas) falarão a mesma língua. 25
  • 26. • Não é possível escrevermos código procedimental com termos do domínio? • Sim, é possível. O problema é que o paradigma procedimental não apoia o baixo hiato representacional entre o negócio e o código, coisa que a orientação a objetos faz muito bem. 26
  • 27. UMA ÚLTIMA PALAVRA • Objetos não são atributos + funções • Mas são estados + comportamento • Métodos não são funções, e vice-versa! • Não crie métodos faz-tudo no seus sistemas, mas objetos que colaborem entre si 27
  • 28. ALAN KAY "Uma vez que você encapsulou de tal forma que existe uma interface entre o interior e o exterior, é possível fazer com que um objeto aja como qualquer coisa, e a razão é simplesmente esta: o que você encapsulou é um computador. Portanto, você fez algo poderoso na ciência da computação, que é pegar o que você transformou em poderoso sem perdê-lo particionando seu “design space”. Isto é um bug em dados procedurais, dados e linguagens procedurais. Acho que isto é a coisa mais perniciosa em linguagens como C++ e Java. Estas acham que estão ajudando o programador tentando se parecer o máximo possível com o “antigo”, mas na verdade, estão ferindo o programador terrivelmente tornando difícil para o programador entender o que realmente é poderoso sobre esta nova metáfora." 28
  • 29. REFERÊNCIAS • KAY, A. The real computer revolution hasn’t happened yet. Viewpoints Research Institute, v. 15, 2007. • BOOCH, G. et al. Object-Oriented Systems Analysis and Design With Applications. 3. ed. Massachusetts: Addison-Wesley, 2007. • EVANS, E. Domain Driven Design - Atacando as Complexidades no Coração do Software. 1. ed. Rio de Janeiro: Alta Books, 2009. • LARMAN, C. Utilizando UML e Padrões. São Paulo: Bookman Editora, 2002. • NELSON, H. J.; ARMSTRONG, D. J.; GHODS, M. Old Dogs and New Tricks. Commun. ACM, v. 45, n. 10, p. 132–137, out. 2002. • NELSON, H. J.; ARMSTRONG, D. J.; NELSON, K. M. Patterns of Transition: The Shift from Traditional to Object-Oriented Development. Journal of Management Information Systems, p. 271–298, 2009. • OWE, O.; KROGDAHL, S. A Biography of Ole-Johan Dahl. p. 1–7, 2004. • https://web.archive.org/web/20110401013847/http://fragmental.com.br/wiki/inde x.php?title=Fantoches • https://www.profissionaisti.com.br/2012/01/alguns-dos-mais-famosos-erros-de- softwares-da-historia/ 29