Paradigma...
Aqui tem algumas definições, tá, de paradigmas,
trazidas da filosofia, o Thomas Kuhn
ou trazido pelo Peter Van Roy.
Tá aí a definição que vocês podem ler.
Mas, em suma, paradigma é uma maneira de pensamento.
Até há quem diga que na programação a gente usa o...
O conceito de paradigma de maneira empobrecida.
Beirando, beirando ou andando de maneira equivocada
mas, basicamente é uma maneira de pensamento.
Quando você diz que tem um paradigma de programação,
as estruturas daquele paradigma definem como você vai programar.
Quando você tem um paradigma procedimental
você vai programar orientado a procedimentos.
Quando você tem um paradigma que se inspira em objetos do mundo real,
você vai programar em módulos
que tentarão simular, em alguma medida,
ou refletir, em alguma medida,
os objetos do mundo real.
Na verdade, o assunto paradigmas ele é um assunto muito rico.
Ele daria, certamente,
dá, aliás, certamente,
uma disciplina toda.
Você tem uma série de autores
que trabalharam a questão de paradigmas.
Alguns que trabalharam de maneira mais bem-estruturada
sendo que eu saliento, nesse âmbito,
justamente, o Van Roy.
O Van Roy tem um livro interessantíssimo,
de umas belas centenas de páginas,
aonde ele traz toda uma classificação sobre os paradigmas.
Ele cria, na verdade, uma classificação multiparametral
para enquadrar as linguagens em paradigmas.
Então ele olha, por exemplo, se tem
estado nomeado ou se tem estado não-nomeado.
Isso tem a ver com o fato de existir um objeto com status,
ou se tudo é passado, sempre,
por parâmetro, por valor, pras funções.
Dito doutra maneira, explicitando melhor o meu discurso.
O estado nomeado,
existe, por exemplo, um módulo, um objeto,
que ele tem estado
e ele pode interagir com outros etc,
pra poder evoluir o seu estado, mas ele está ali.
Já o estado não-nomeado,
na verdade, você tem entes
que são passados de funções em funções
e essas funções vão alterando
o estado daquilo, mas aquilo não está
num lugar fixo, com um estado fixo,
aquilo vai evoluindo no tempo
sem a percepção de um elemento
referenciado num lugar dado
com estado que evolui em si.
Na verdade, o estado não-nomeado é algo que vai passando
de elemento... De processo pra processo
e vai se transformando naquele processo
sem existir de maneira fixa e pragmática num local.
Bom, essa minha explicação ficou um pouco abstrata,
porque pra gente entender melhor isso que eu tô dizendo,
naturalmente, a gente teria que ler todo o trabalho do... Do Van Roy.
Mas provavelmente depois, vocês, aí, em algum momento da vida
relerem o Van Roy e re-escutarem
o meu discurso, isso vai ficar ainda mais entendível.
Não só estado nomeado
e estado não nomeado que trabalhou o Van Roy,
ele trabalhou com outros elementos:
Ele trabalhou com um parâmetro chamado
determinismo observável ou não-determinismo observável;
com... Se o problema permite,
o Turing-completo ou não;
qual o nível de closure,
ou de fechamentos, que tem os programas
ou digo de outra maneira,
se eles têm módulos ou não têm
e qual o nível de encapsulamento desses módulos;
ele também trabalha com um nível de baixo-alto nível
que a programação permite.
Enfim, longa história curta,
o Van Roy, criou uma classificação pros paradigmas,
reservadas proporções como o Darwin criou lá a árvore da vida
pra classificar as espécies no reino animal. Aliás, no reino da vida.
Então aqui dá um belo estudo, sabe, de...
De horas, de dias,
pra entender toda essa complexidade que o Van Roy... O Van Roy traz.
Se você não quer ler um livro dele agora, de páginas em páginas
você pode ler um paper dele disponível
que é algo como, entre parênteses aqui tá,
Paradigms for dummies
que ele faz um resumo da ópera.
Interessante, é um paper inglês,
eu acho que compensa a leitura.
Mas isso daqui como, obviamente, como adendo
ao seu conhecimento de paradigmas.
Vamos resumir toda essa história, que eu tô falando pra vocês
de uma maneira bastante simplória,
aliás, extremamente simplória,
mas que permite a gente ter uma noção boa,
de toda essa... Esse universo aqui exposto pelo Van Roy.
Tá aqui essa simplificação.
Entre aspas, "uma simplificação veemente".
Você pode olhar os paradigmas de programação como dois grandes grupos.
Paradigma imperativo e paradigma declarativo.
No imperativo, que é onde vocês têm trabalhado até agora
você tem o procedimental,
como a linguagem C, a linguagem Pascal, Clipper, enfim.
E você vai ter o paradigma orientado a objetos,
que é o principal foco desse nosso estudo aqui.
Além do paradigma orientado a objetos,
e não raro tem associado a ele o paradigma orientado a eventos
que já é uma evolução do paradigma orientado a objetos.
No outro lado, você tem o paradigma declarativo
aonde você mais declara do que programa
e ali entra, por exemplo, o paradigma funcional.
Paradigma funcional, eu dizia pra vocês que ele , não raro,
trabalha com passagem de parâmetro por valor entre as funções.
E além disso, em algumas linguagens como
Prolog e Lisp você trabalha com noção de recursão.
Quando você trabalha com isso,
as pessoas acham que você tá programando em um pouco mais alto nível
e procuraram classificar então aqui, nessa classificação simplória,
o funcional como declarativo, mas daqui a pouco eu volto essa questão.
Ainda no declarativo, tem o paradigma lógico
Aonde você salienta o baseado em regras,
que é aquela situação onde você tem lá as decisões
em loopings automatizados, por assim dizer,
animados por máquinas de inferência.
Bem entendido, isso daqui é uma simplificação veemente,
agora sim, entre aspas, talvez até "rude".
Aqui é só pra você ter um panorama,
um panorama simplificado daquela complexidade que o Van Roy trouxe pra nós, tá.
Obviamente que toda simplificação tem imperfeição.
Então você pega, por exemplo, a orientação a eventos
você vai ter procedimental com a orientação a eventos também.
Pega, por exemplo, o Visual Basic.
As primeiras versões do Visual Basic era procedimental
e orientado a eventos.
Depois que o Visual Basic começa a incorporar a orientação a objetos
Pega a questão do funcional que eu dizia ali há pouco, tá.
Facilmente você vai ter, na verdade, o funcional
navegando entre o declarativo e o imperativo.
Depende, na verdade, da linguagem de programação que você ta utilizando.
Pega o próprio C++, foco do nosso estudo aqui, tá.
Ele comporta, largamente, o procedimental orientado a objetos conjuntamente.
Então, isso aqui é uma versão, novamente, simplificada pra você entender o big picture,
a figura geral da coisa, mas, novamente, uma simplificação.
Mas é legal, porque já permite você posicionar, mais ou menos, as coisas, tá.
Eu imagino isso daqui como um posicionador,
onde você vai colocando as linguagens e vai dizer, mais ou menos,
em quais quadrados que elas se encontram.
À luz do que eu disse, você pode olhar o próximo slide.
Nesse próximo slide aqui, você tem a...
talvez uma visão um pouco mais justa das linguagens.
Pega o C++, por exemplo, ele tá ali no conjunto dos procedimentais
e também tá no conjunto de orientação a objetos.
Pega o Smalltalk, ele tá só no conjunto orientado a objetos.
Pega lá o Prolog,
ele tá no conjunto do... do declarativo.
O Lisp, ele é do declarativo, mas já tá se aproximando mais aqui do procedimental.
E assim vai tá, então, pra vocês entenderem que existem os paradigmas e existem as linguagens.
E as linguagens podem estar num paradigma só
ou podem estar conjunto de outros paradigmas.
Além das linguagens poderem estar em diversos paradigmas conforme a situação,
elas também têm a possibilidade de serem mais alto ou mais baixo nível.
Na verdade, até o mais baixo ou alto nível
também ajuda a classificá-las em alguma medida
com relação aos paradigmas que elas se encontrariam.
Mas vamos focar aqui, um pouquinho, no C++, que é o que me interessa.
C++ é algo muito interessante. Tem o C e o C++, tá.
O C é procedimental.
O C permite você programar desde o baixo nível até o alto nível.
Você pode programar usando comandos de alto nível sem se preocupar
com detalhes como operador bit-a-bit,
Ah, em algumas situações, você também nem aloca memória
usa só elementos estáticos, e por aí vai.
Se você olha o C++, o C++ não perde essas características,
mas, ao mesmo tempo, ele permite aumentar o nível
mais ainda quando você consegue programar orientado a objetos.
Criar lá o seu módulo Dragão, criar o seu módulo
Boitatá, o seu módulo Asteroide, Meteoro, Jogador etc.
Então isso aqui é importante.
Linguagem de programação trabalha no alto e baixo nível,
Algumas linguagens permitem melhor navegação entre o baixo e alto nível,
saliento o C e o C++, o que explica o impacto industrial que elas têm.
Se não explica, ajuda a explicar, bem entendido.
Bom, aqui é o slide que...
Procura classificar, então, linguagens imperativas
em sub-paradigmas que é o procedimental e o OO.
Você tem ali como exemplos do procedimental imperativo o C e o Pascal.
No OO você tem o C++, Object Pascal, o Java e o C#.
Vejam que o C++, na verdade, ele vai tá na fronteira.
Ele vai tá encavalado ali na fronteira, porque ele também pode trabalhar como procedimental.
Então ele poderia estar encavalado aqui pra fronteira desse tabelamento.
Bom, tudo isso considerado, vamos focar um pouquinho mais na orientação a objetos em si.
Como tenho dito aí, a... A OO, orientação a objetos, é um paradigma,
modelo genérico, conjunto de ideias, pra ser simplista,
para o projeto e implementação de software,
tal como o paradigma procedimental o é.
No que concerne a implementação de software,
existem linguagens de programação que suportam, naturalmente, esses paradigmas,
sublinhando aqui o C++.
Neste contexto, um objeto pode ser entendido como um módulo coeso do software.
É, à luz de tudo que eu já tinha dito aí pra vocês, né, a hora que eu leio essa definição,
ela é totalmente coerente com o que foi dito.
A orientação a objetos se inspira nos objetos do mundo real.
Então, é natural que a hora que você programe o software,
que o seus módulos programados eles tenham cara de objetos
programado em função do tipo dos objetos do mundo real,
em função da classe dos objetos do mundo real.
Então você vai programar, por exemplo, o módulo Carro:
Carro1; Carro2; Carro3.
Esse Carro1, Carro2, Carro3, são os objetos
e você tem um tipo dos objetos ou a classe dos objetos
que é do tipo ou a classe Carro.
Outra coisa interessante a ser dita com relação ao paradigma OO em si,
é que o paradigma ele é muito mais do que um paradigma de programação,
ele é um paradigma de concepção de sistemas.
Inclusive de sistemas de software.
Tanto é, que atualmente, você além de ter linguagens de programação orientada a objetos
você tem linguagens de modelagem orientado a objetos.
Não se enganem.
A hora que você vai fazer um software, você não sai programando o software
Software é um artefato de engenharia, você tem procedimento de engenharia.
Quando você vai construir uma casa, você não sai levantando parede.
Tem todo um método, um ciclo, de engenharia a ser cumprido.
Entender quais são os requisitos que você quer pra aquela casa. Um andar, dois andares,
metragem, o tipo de paredes que vai utilizar, o tipo de telhado que vai ter,
análise do solo se suporta dois andares, por exemplo, e assim vai.
Uma vez que você fez: análise do que tem que ser feito;
se é viável o que tem que ser feito. Você ainda tem toda a parte de projeto.
Você vai criar planta baixa. Você vai criar, talvez, simulação
daquela casa, em algum... Em algum simulador.
Você vai fazer análise estrutural,
seja de maneira tradicional, seja com a ajuda de simuladores
Tem todo um procedimento, aqui, de engenharia a ser cumprido.
Software é a mesma coisa.
Software, você vai antes, entender o que tem que ser feito.
As necessidades, evoluindo para os requisitos pra depois você evoluir pra modelagem.
Aonde tem a análise de projeto.
Você consegue projetar todo um software
tal qual você faz uma planta baixa de uma casa.
Você consegue, por exemplo, fazer todo um modelo, em uma linguagem de modelagem,
definindo quais são as classes que gerarão os objetos,
quais são as relações entre essas classes,
e, portanto, que relações terão os objetos.
Então, antes de fazer um software, um jogo,
com Dragão, com Jogador, com Meteoro, com Boitatá,
antes você vai modelar o módulo, ou o tipo de módulo, Dragão,
o tipo Jogador, o tipo Meteoro, através de alguns artifícios,
modelar as relações, entre esses elementos, antes de programar.
É só pra... Esse discurso todo aqui, é só pra contar pra vocês que a orientação a objetos
ela vai além da programação, também envolvendo a modelagem e muito mais.
Aí, tem uma série de vantagens da orientação a objetos, tá.
Você programar orientado aos módulos do mundo real,
já traz as vantagens, inclusive, do mundo que você tá observando.
O mundo que você observa ele é razoavelmente estável.
Todas as demais engenharias trabalham já,
ou senão todas, da grande parte das engenharias tradicionais,
já trabalham orientado a objetos, porque elas não tem opção.
Você pega a Engenharia Mecânica. Ela trabalha com objetos.
Vai montar um carro, montar um Fusca.
O Fusca é uma... é um objeto, composto de outros objetos.
Por exemplo, um motor. Por exemplo, as rodas, o eixo,
ali a plataforma do carro que me foge o nome agora.
O chassi.
Então, são um conjunto de objetos, e esses objetos se relacionam entre si
através de um conjunto de lógicas.
Você não faz um carro como se fosse um objeto único.
Você faz usando, na verdade, composições de objetos.
Você, por exemplo, não tem o eixo soldado na... no aro.
Você tem ali uma maneira deles se relacionarem
e se encaixarem e colaborarem conjuntamente,
pra alcançar a função de movimento.
Lá, o motor, que vai afetar todo o movimento subsequentemente,
ele por si é um objeto também que se relaciona com os demais objetos.
Ele vai se relacionar, por exemplo, lá,
com todo os sistema de engrenagens que movimenta o carro.
E interessante que o objeto se relaciona com outros objetos
e, ao mesmo tempo, o motor, ele é uma composição de objetos.
Então, no motor, você vai ter... O motor não é uma peça única.
Você vai ter lá, câmara de combustão.
Você vai ter carburador. Você vai ter, enfim, uma série de outros objetos que o compõe.
Então, observando esses objetos... Esses sistema que se orientam a objetos naturalmente,
você vão ver as vantagens deles.
Por exemplo, se eu tenho um motor que não é um elemento único.
Ele... Ele representa um elemento único, mas ele é composto por outros elementos.
Se eu tenho um problema, por exemplo, no carburador. Eu preciso trocar o motor inteiro?
Não.
Como carburador é um elemento auto-contido que se comunica com outros,
através de um conjunto de engenhos ali.
Eu vou lá, e desparafuso o carburador, ponho o carburador novo,
e sigo com o meu motor funcionando.
Com isso, você vai ter o quê? Vai ter redução no custo de manutenção.
Você vai ter aumento de reutilização de objetos.
Porque o carburador estragou, eu não preciso jogar o meu motor inteiro fora.
Troca o carburador.
Aqui, em termos de código, é a mesma coisa, tá.
Imagina que você fez um jogo lá, todo grande, orientado a objetos.
E você fez um módulo Dragão.
De repente, vem um colega seu e faz um Dragão melhor.
Dragão++.
Você vai jogar todo o código fora que você criou? Não, você substitui só o Dragão ali.
Bom, em termos de software aí, na redução de custo, aumento de reutilização,
também melhora a representação da solução pretendida.
Você enxerga mais facilmente os módulos.
Dado que você usando uma representação que é comum
pra sua cognição, que é a orientação a objetos.
Você vai ter aumento de segurança de sistemas. É verdade.
Por exemplo, se eu já testei, um dado tipo de pneu,
que ele tem uma boa frenagem em chuva.
Eu posso reutilizar aquele tipo de pneu em vários outros tipos de carros.
Posso pega aquele mesmo pneu e utilizar em toda a gama de carros que é produzida,
Se eu quiser ter a segurança de um pneu que... Que reage bem em ambiente chuvoso.
Em termos de software, eu posso ter o módulo, por exemplo, de Login.
Eu sei que meu módulo de Login funciona bem.
Ele tem uma boa criptografia interna, ele foi testado durante anos.
Eu reutilizo aquele módulo, aumentando a segurança do sistema.
Aqui falando só um aspecto de segurança,
tem outros aspectos de segurança que você pode tratar.
E assim vai, tá. Então, tem uma série de... de vantagens
que você encontra aqui na... no tocante a orientação a objetos
que eu não vou me estender no discurso, porque vocês podem ler no material
tranquilamente e até intuir,
já que a orientação a objetos tem essa vantagem também de ser intuitiva.