aspectos do aprendizado do paradigma orientado a objetos por programadores procedimentais

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


• 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

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


• 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


• 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

Obrigado!

Contatos:

[email protected]

br.linkedin.com/in/rodrigovp

30