Quais foram as condições históricas que levaram a programação orientada a objetos a se tornar um grande paradigma de programação?

14

Quais foram alguns dos fatores econômicos (e outros históricos) que fizeram com que as linguagens de programação orientadas a objetos se tornassem influentes? Sei que o Simula começou, mas foi a adoção de idiomas OOP devido às crescentes necessidades dos negócios? Ou, a adoção foi mais devida às coisas novas que poderiam ser feitas com os idiomas OOP?

Editar Estou realmente mais interessado em saber se houve alguns fatores externos aos próprios idiomas que lhes permitiram se estabelecer.

technology programming-languages

— ihtkwot
fonte

Isso faz sentido, mas acho que estava mais interessado nas circunstâncias externas que estavam acontecendo durante o desenvolvimento. Pode muito bem ser que fatores externos tenham um efeito limitado.

Garanto que, mesmo para uma pergunta sobre fatores externos, programmers.stackexchange é um local melhor. Tem uma tonelada de pessoas que trabalham ativamente no setor e muitas que trabalham desde que o setor decolou. É muito mais provável que você encontre uma pessoa que tenha uma excelente resposta para sua pergunta do que aqui.

— Opte

2

O Smalltalk não iniciou. Simula criou os conceitos básicos de orientação a objetos. O que o Smalltalk fez foi pegar essas idéias e transformá-las em um modelo muito diferente e se apropriar do nome. Mas vale a pena notar que nenhuma linguagem que segue o modelo Smalltalk de OO jamais foi realmente muito bem-sucedida na criação de programas. (Com exceção do Objective-C, que é um caso especial: a Apple empurra a garganta de todos, mas ninguém fora do ecossistema da Apple o usa.) Todas as linguagens OO de sucesso: C ++, Delphi, Java, C #, etc, use o modelo Simula.

— Mason Wheeler

1

Tijolos de brinquedo Lego pode caber em como uma influência externa ...

— Jamie F

1

@Mason: não sei o que divide os modelos Simula e Smalltalk. Onde você colocaria Ruby? LUA? Pitão? Javascript?

— Kevin cline #

10

Resposta curta

Eu acho que foi a agitação dos projetos de software anteriores aos dias de OO. OO ajudou adicionando o conceito fundamentalmente crítico - Modele o mundo real .

A primeira linguagem de programação orientada a objetos foi a Simula em 1967. No entanto, naquela época, o desenvolvimento de software em geral ainda estava nos laboratórios e a maioria dos paradigmas ainda estava mais próxima do caso do hardware .

Ao longo de mais de uma década, o desenvolvimento de software para aplicativos corporativos cresceu e o desenvolvimento de software em geral aumentou durante toda a década de 1970. Os idiomas que ainda hoje sobrevivem a essa idade (antes de 1980) eram C, Cobol, Fortran e similares. A maioria desses idiomas é procedural. O Lisp também existia desde aquele dia - no entanto, não tenho certeza se essa era uma linguagem de propósito geral proeminente para o desenvolvimento comercial. O famoso termo modelo de cachoeira também foi cunhado no início dos anos 70.

Na maioria dos ambientes comerciais, o elemento mais importante emergente no desenvolvimento de software foi o gerenciamento de projetos. Havia uma necessidade extrema de orçamentos apertados e pelo menos previsíveis e requisitos de gerenciamento congelados para garantir que o projeto chegasse à linha de chegada de maneira respeitável. Durante esse período, foi também um dos meses míticos em 1975.

Acho que no final dos anos 70 as pessoas estavam esgotadas - pois as linguagens processuais não cumpriam essas promessas. E um novo paradigma Orientado a objetos, que existia desde então, tornou-o grande. Embora as pessoas possam discordar, acho que o C ++, que ajuda a familiaridade e experiência comprovada, e o C, e a Promessa de Orientação a Objetos (originalmente com o nome C com Classes) em 1983 foram a pedra angular do sucesso da programação orientada a objetos.

Algumas referências para mais perspectivas - http://journal.thedacs.com/issue/43/88

Então, por que OO?

Eu acho que naqueles dias (se você olhar para o ponto de vista do sucesso do projeto) - fazia sentido que o que você pudesse entender melhor fosse melhor administrável. A metodologia orientada a objetos com a promessa "... tudo na vida é um objeto" parecia mais senso comum antes mesmo de ter provado ser significativo. O sucesso prático desse fator foi a própria noção de modelar suficientemente o mundo real e o problema em questão antes de pular a arma - o que acho algo fundamentalmente novo que o OO ofereceu que nenhum outro paradigma ofereceu até aquela data. E, definitivamente, dado que esse paradigma o forçou a pensar um pouco antes de codificar mais do que linguagens procedurais, ele mostrou um sucesso visível nos projetos de software que empregaram e, desde então, eles se deram bem!

EDIT
Eu também acrescentaria que as linguagens de programação evoluíram simultaneamente em paralelo a esses conceitos fundamentais (paradigma OO, Aspect, máquinas virtuais). Cada novo conceito e pensamento renovado surgiram apenas quando uma nova linguagem de programação o dominou - mantenha apenas a familiaridade, mas mude os fundamentos de testemunho! Ao mesmo tempo - esse novo conceito e novas linguagens só surgiram por causa de novos problemas de negócios. 1980 - OO para software de grande escala, 1990 Java na era da Internet, PHP / ASP e muitos outros para web. A inovação em linguagens de programação também foi impulsionada principalmente pela necessidade descontínua do mercado.

Em resumo, o início dos anos 80 foi a época em que o software comercial em larga escala decolou - enquanto projetos com linguagens procedurais tinham problemas, o OO mostrava a melhor luz e tornava os projetos mais bem-sucedidos.

— Dipan Mehta
fonte

Quais eram as características do turno e para onde ir? Fim dos anos 70. O que os desenvolvedores entendidos entendem que é hora de ir? Cansado de processual, sim, mas deve haver ben de primos de alternativas?

— 1/12 independente

@Jonas - ok - alterou a resposta.

— Dipan Mehta

Quanto ao sucesso histórico que estamos avaliando, podemos dizer definitivamente que a familiaridade desempenha algum papel. C (foi sucessor de B), C ++ foi um C melhor, embora OO fosse supostamente uma mudança de paradigma. Até o Java foi um salto pronto para o C ++ (que era mais parecido com o C ++ sem problemas no C ++, por exemplo, memória e portabilidade). A maioria dessas linguagens atravessou o abismo adquirindo o espaço existente de maneira mais eficaz, mesmo tendo algo mais fundamental nelas. Mais ainda, porque toda linguagem adquirirá alguns programadores que já conhecem outras linguagens de programação. MAS isso pode não ser sempre verdade!

— Dipan Mehta

1

Eu acrescentaria também que as linguagens de programação evoluíram simultaneamente em paralelo a tais conceitos fundamentais (paradigma OO, Aspect, máquinas virtuais). Cada novo conceito e pensamento renovado surgiram apenas quando uma nova linguagem de programação o dominou - mantenha apenas a familiaridade, mas mude os fundamentos do núcleo. ! Ao mesmo tempo - esse novo conceito e novas linguagens só surgiram por causa de novos problemas de negócios. 1980 - OO para software de grande escala, 1990 Java na era da Internet, PHP / ASP e muitos outros para a web. A inovação em linguagens de programação também foi impulsionada principalmente pela necessidade descontínua do mercado.

— Dipan Mehta

1

"Modelar o mundo real" parece conclusivo, mas na maioria dos casos, isso não acontece. A Customerclasse não possui métodos como eatLunch, goToWorkou sleep, embora isso seja o que os clientes fazem no mundo real . A Productclasse tem vários métodos, embora a maioria dos produtos não tenha exatamente nenhum comportamento no mundo real . Portanto, eu argumentaria que o modelo OO corresponde apenas (mais ou menos) em termos de propriedades, mas não em termos de comportamento, com o mundo real. Mas você não precisa de OO para ter um modelo de dados que corresponda a objetos do mundo real. Tipos de registro é tudo o que é preciso.

— precisa saber é o seguinte

6

Eu acho que o maior motivo foi o sucesso de interfaces gráficas de usuário como X e Windows. Uma GUI consiste em vários objetos que têm um comportamento por conta própria, algo que o OO é capaz de representar de perto.

Por outro lado, uma interface de usuário com base em texto (que não tenta se parecer com uma GUI) geralmente simplesmente segue um padrão de resposta de comando, que pode ser facilmente implementado em uma linguagem processual. Regras de negócios e coisas semelhantes foram implementadas com linguagens processuais por décadas, sem muitos problemas, e ainda hoje muitos programas OO para aplicativos de negócios são bastante processuais; com objetos estúpidos que mantêm os dados e objetos sem estado que contêm as regras de negócios; o primeiro poderia ser registros em um idioma processual; o posterior poderia ser, bem, procedimentos.

— user281377
fonte

4

Eu vejo o POO como um passo evolutivo natural do código processual:

Código de procedimento: diga à máquina para fazer A e depois para B.
OOP: Empacote as instruções de procedimento em blocos muito reutilizáveis, definindo interfaces / entradas / saídas. (Aviso: simplificação.)

Tenho certeza de que alguém com uma visão mais ampla vai entrar em cena, mas parece que essa foi uma progressão natural, simplesmente permitindo que os programadores produzam código mais rapidamente: ou seja, permitem uma maior reutilização de código.

Nesta visão, o maior fator externo foi o custo reduzido de potência do processador (versus o custo da mão-de-obra do desenvolvedor para criar programas típicos): a sobrecarga da computação no uso de classes OOP tornou-se menos preocupante do que a economia de tempo do desenvolvedor. (Essa mesma compensação entre despesas de CPU e despesas de programadores influenciou muitos outros aspectos da programação.)

— Jamie F
fonte

2

No começo, havia uma programação imperativa (se você pudesse chamar assim). Instruções simples que informavam ao mainframe o que e como deveria ser calculado. Essas linguagens de programação usavam saltos incondicionais e outras instruções "não estruturadas", a maioria delas exóticas para os padrões atuais.

Então alguém criou estruturas para programação. O que, enquanto, faz enquanto e que conhecemos hoje. Foi uma grande inovação, já que agora aplicativos com fluxo relativamente complexo podem ser escritos e entendidos facilmente. Assim nasceu a programação estruturada.

Depois vieram outras pessoas que disseram que você precisava repetir muito código aqui e ali e era um pesadelo manter isso, para que uma maneira de reutilizar o código fosse inventada. As pessoas criaram procedimentos e funções para delimitar pedaços de código reutilizáveis. Isso também deu origem aos princípios de encapsulamento e responsabilidade única.

Alguns acadêmicos disseram que a funcionalidade deveria estar intimamente ligada aos dados em que está trabalhando. Em seguida, eles adicionaram os conceitos de herança para reutilização de código e polimorfismo para corresponder à maneira lógica pela qual a classificação funcionava na vida real. Assim, nasceram as linguagens de programação de terceira geração e o POO.

— linkerro
fonte