aspectos do aprendizado do paradigma orientado a objetos por programadores procedimentais
TRANSCRIPT
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 sistema4
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 clientespossam utilizá-lo, usando orientação a objetos e modelode 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 umainterface entre o interior e o exterior, é possível fazer com queum objeto aja como qualquer coisa, e a razão é simplesmenteesta: o que você encapsulou é um computador. Portanto, vocêfez algo poderoso na ciência da computação, que é pegar o quevocê 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 perniciosaem linguagens como C++ e Java. Estas acham que estãoajudando o programador tentando se parecer o máximo possívelcom o “antigo”, mas na verdade, estão ferindo o programadorterrivelmente tornando difícil para o programador entender o querealmente é 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/index.php?title=Fantoches
• https://www.profissionaisti.com.br/2012/01/alguns-dos-mais-famosos-erros-de-softwares-da-historia/
29