Programação orientada a objetos

Da Wikipédia, a enciclopédia livre
Ir para a navegação Saltar para pesquisar

Paradigmas de programação

A programação orientada a objetos ( POO ) é um paradigma de programação baseado no conceito de " objetos ", que pode conter dados e código : dados na forma de campos (geralmente conhecidos como atributos ou propriedades ) e código, na forma de procedimentos (muitas vezes conhecido como métodos ).

Uma característica dos objetos é que os próprios procedimentos de um objeto podem acessar e frequentemente modificar os campos de dados de si mesmo (os objetos têm uma noção de ou ). Na POO, os programas de computador são projetados a partir de objetos que interagem uns com os outros. [1] [2] As linguagens OOP são diversas, mas as mais populares são baseadas em classes , o que significa que objetos são instâncias de classes , que também determinam seus tipos . thisself

Muitas das linguagens de programação mais usadas (como C++, Java, Python, etc.) são multiparadigmas e suportam programação orientada a objetos em maior ou menor grau, normalmente em combinação com programação imperativa e procedural . As linguagens orientadas a objetos significativas incluem: Java , C++ , C# , Python , R , PHP , Visual Basic.NET , JavaScript , Ruby , Perl , SIMSCRIPT , Object Pascal , Objective-C , Dart, Swift , Scala , Kotlin , Common Lisp , MATLAB e Smalltalk .

História

Notação UML para uma classe. Esta classe Button tem variáveis para dados e funções . Por meio de herança, uma subclasse pode ser criada como subconjunto da classe Button. Objetos são instâncias de uma classe.

A terminologia que invoca "objetos" e "orientado" no sentido moderno de programação orientada a objetos fez sua primeira aparição no MIT no final dos anos 1950 e início dos anos 1960. No ambiente do grupo de inteligência artificial , já em 1960, "objeto" poderia se referir a itens identificados ( átomos LISP ) com propriedades (atributos); [3] [4] Alan Kay mais tarde citou uma compreensão detalhada dos componentes internos do LISP como uma forte influência em seu pensamento em 1966. [5]

Eu pensei em objetos sendo como células biológicas e/ou computadores individuais em uma rede, apenas capazes de se comunicar com mensagens (então as mensagens vieram bem no início – demorou um pouco para ver como fazer mensagens em uma linguagem de programação com eficiência suficiente para ser útil).

Alan Kay, [5]

Outro exemplo inicial do MIT foi o Sketchpad criado por Ivan Sutherland em 1960-1961; no glossário do relatório técnico de 1963 baseado em sua dissertação sobre o Sketchpad, Sutherland definiu noções de "objeto" e "instância" (com o conceito de classe coberto por "mestre" ou "definição"), embora especializado em interação gráfica. [6] Além disso, uma versão do MIT ALGOL , AED-0, estabeleceu uma ligação direta entre estruturas de dados ("plexes", nesse dialeto) e procedimentos, prefigurando o que mais tarde foram denominados "mensagens", "métodos" e "funções de membro". ". [7] [8]

O Simula introduziu conceitos importantes que hoje são parte essencial da programação orientada a objetos, como class e object , herança e vinculação dinâmica . [9] A linguagem de programação orientada a objetos Simula foi utilizada principalmente por pesquisadores envolvidos com modelagem física , como modelos para estudar e melhorar a movimentação de navios e seu conteúdo através de portos de carga. [9]

Na década de 1970, a primeira versão da linguagem de programação Smalltalk foi desenvolvida na Xerox PARC por Alan Kay , Dan Ingalls e Adele Goldberg . Smalltalk-72 incluiu um ambiente de programação e foi tipado dinamicamente , e a princípio foi interpretado , não compilado . Smalltalk tornou-se conhecido por sua aplicação de orientação a objetos no nível da linguagem e seu ambiente de desenvolvimento gráfico. Smalltalk passou por várias versões e o interesse pela linguagem cresceu. [10]Embora o Smalltalk tenha sido influenciado pelas ideias introduzidas no Simula 67, ele foi projetado para ser um sistema totalmente dinâmico no qual as classes podem ser criadas e modificadas dinamicamente. [11]

Na década de 1970, Smalltalk influenciou a comunidade Lisp a incorporar técnicas baseadas em objetos que foram introduzidas aos desenvolvedores através da máquina Lisp . A experimentação com várias extensões para Lisp (como LOOPS e Flavors introduzindo herança múltipla e mixins ) acabou levando ao Common Lisp Object System , que integra programação funcional e programação orientada a objetos e permite extensão por meio de um protocolo Meta-objeto . Na década de 1980, houve algumas tentativas de projetar arquiteturas de processador que incluíam suporte de hardware para objetos na memória, mas não foram bem-sucedidas. Exemplos incluem oIntel iAPX 432 e o Linn Smart Rekursiv .

Em 1981, Goldberg editou a edição de agosto da Byte Magazine , apresentando Smalltalk e programação orientada a objetos para um público mais amplo. Em 1986, a Association for Computing Machinery organizou a primeira Conferência sobre Programação, Sistemas, Linguagens e Aplicativos Orientados a Objetos (OOPSLA), que inesperadamente contou com a participação de 1.000 pessoas. Em meados da década de 1980, o Objective-C foi desenvolvido por Brad Cox , que havia usado Smalltalk na ITT Inc. , e Bjarne Stroustrup , que havia usado Simula para sua tese de doutorado, acabou criando o C++ orientado a objetos . [10] Em 1985, Bertrand Meyertambém produziu o primeiro desenho da linguagem Eiffel . Focada na qualidade do software, Eiffel é uma linguagem de programação puramente orientada a objetos e uma notação que suporta todo o ciclo de vida do software. Meyer descreveu o método de desenvolvimento de software Eiffel, baseado em um pequeno número de ideias-chave da engenharia de software e ciência da computação, em Object-Oriented Software Construction . Essencial para o foco de qualidade da Eiffel é o mecanismo de confiabilidade de Meyer, Design by Contract , que é parte integrante do método e da linguagem.

O gráfico do índice de popularidade da linguagem de programação TIOBE de 2002 a 2018. Nos anos 2000, o Java orientado a objetos (azul) e o C procedural (preto) competiam pela primeira posição.

No início e meados da década de 1990, a programação orientada a objetos desenvolveu-se como o paradigma de programação dominante quando as linguagens de programação que suportavam as técnicas tornaram-se amplamente disponíveis. Estes incluíam Visual FoxPro 3.0, [12] [13] [14] C++ , [15] e Delphi [ citação necessária ] . Seu domínio foi reforçado pela crescente popularidade das interfaces gráficas de usuário , que dependem fortemente de técnicas de programação orientadas a objetos. Um exemplo de uma biblioteca GUI dinâmica intimamente relacionada e linguagem OOP pode ser encontrado nos frameworks Cocoa no Mac OS X , escritos emObjective-C , uma extensão de mensagem dinâmica orientada a objetos para C baseada em Smalltalk. Os kits de ferramentas OOP também aumentaram a popularidade da programação orientada a eventos (embora esse conceito não se limite a OOP).

Na ETH Zürich , Niklaus Wirth e seus colegas também estavam investigando tópicos como abstração de dados e programação modular (embora isso fosse de uso comum na década de 1960 ou antes). Modula-2 (1978) incluiu ambos, e seu projeto subsequente, Oberon , incluiu uma abordagem distinta para orientação a objetos, classes e afins.

Recursos orientados a objetos foram adicionados a muitas linguagens existentes anteriormente, incluindo Ada , BASIC , Fortran , Pascal e COBOL . Adicionar esses recursos a linguagens que não foram inicialmente projetadas para eles geralmente levava a problemas de compatibilidade e manutenção do código.

Mais recentemente, surgiram várias linguagens que são principalmente orientadas a objetos, mas que também são compatíveis com a metodologia procedural. Duas dessas linguagens são Python e Ruby . Provavelmente, as linguagens orientadas a objetos recentes mais importantes comercialmente são Java , desenvolvida pela Sun Microsystems , bem como C# e Visual Basic.NET (VB.NET), ambas projetadas para a plataforma .NET da Microsoft. Cada um desses dois frameworks mostra, à sua maneira, o benefício de usar OOP criando uma abstração da implementação. VB.NET e C# suportam herança entre linguagens, permitindo classes definidas em uma linguagem para classes de subclasse definidas na outra linguagem.

Características

A programação orientada a objetos usa objetos, mas nem todas as técnicas e estruturas associadas são suportadas diretamente em linguagens que alegam oferecer suporte a POO. Ele executa operações em operandos. Os recursos listados abaixo são comuns entre as linguagens consideradas fortemente orientadas a classes e objetos (ou multiparadigma com suporte OOP), com notáveis ​​exceções mencionadas. [16] [17] [18] [19]

Compartilhado com idiomas não OOP

O suporte de programação modular fornece a capacidade de agrupar procedimentos em arquivos e módulos para fins organizacionais. Os módulos têm namespaces para que os identificadores em um módulo não entrem em conflito com um procedimento ou variável que compartilha o mesmo nome em outro arquivo ou módulo.

Objetos e classes

As linguagens que oferecem suporte à programação orientada a objetos (OOP) normalmente usam herança para reutilização e extensibilidade de código na forma de classes ou protótipos . Aqueles que usam classes suportam dois conceitos principais:

  • Classes – as definições para o formato de dados e procedimentos disponíveis para um determinado tipo ou classe de objeto; também podem conter dados e procedimentos (conhecidos como métodos de classe), ou seja, as classes contêm os membros de dados e funções-membro
  • Objetos – instâncias de classes

Objetos às vezes correspondem a coisas encontradas no mundo real. Por exemplo, um programa gráfico pode ter objetos como "círculo", "quadrado", "menu". Um sistema de compras online pode ter objetos como "carrinho de compras", "cliente" e "produto". [20] Às vezes, objetos representam entidades mais abstratas, como um objeto que representa um arquivo aberto, ou um objeto que fornece o serviço de tradução de medidas usuais para métricas.

Cada objeto é considerado uma instância de uma classe específica (por exemplo, um objeto com seu campo de nome definido como "Mary" pode ser uma instância da classe Employee). Os procedimentos na programação orientada a objetos são conhecidos como métodos ; variáveis ​​também são conhecidas como campos , membros, atributos ou propriedades. Isso leva aos seguintes termos:

  • Variáveis ​​de classe – pertencem à classe como um todo ; há apenas uma cópia de cada um
  • Variáveis ou atributos de instância – dados que pertencem a objetos individuais ; cada objeto tem sua própria cópia de cada um
  • Variáveis ​​de membro – refere-se às variáveis ​​de classe e de instância que são definidas por uma classe específica
  • Métodos de classe – pertencem à classe como um todo e têm acesso apenas a variáveis ​​de classe e entradas da chamada de procedimento
  • Métodos de instância – pertencem a objetos individuais e têm acesso a variáveis ​​de instância para o objeto específico em que são chamados, entradas e variáveis ​​de classe

Os objetos são acessados ​​como variáveis ​​com estrutura interna complexa e, em muitas linguagens, são efetivamente ponteiros , servindo como referências reais para uma única instância do referido objeto na memória dentro de um heap ou pilha. Eles fornecem uma camada de abstração que pode ser usada para separar o código interno do externo. O código externo pode usar um objeto chamando um método de instância específico com um determinado conjunto de parâmetros de entrada, ler uma variável de instância ou gravar em uma variável de instância. Os objetos são criados chamando um tipo especial de método na classe conhecido como construtor . Um programa pode criar muitas instâncias da mesma classe enquanto é executado, que operam independentemente. Essa é uma maneira fácil de usar os mesmos procedimentos em diferentes conjuntos de dados.

A programação orientada a objetos que usa classes às vezes é chamada de programação baseada em classes , enquanto a programação baseada em protótipos normalmente não usa classes. Como resultado, uma terminologia significativamente diferente, porém análoga, é usada para definir os conceitos de objeto e instância .

Em algumas linguagens classes e objetos podem ser compostos usando outros conceitos como traits e mixins .

Baseado em classe vs baseado em protótipo

Em linguagens baseadas em classes, as classes são definidas de antemão e os objetos são instanciados com base nas classes. Se dois objetos maçã e laranja são instanciados da classe Fruit , eles são inerentemente frutas e é garantido que você pode tratá-los da mesma maneira; por exemplo, um programador pode esperar a existência dos mesmos atributos como color ou sugar_content ou is_ripe .

Em linguagens baseadas em protótipos, os objetos são as entidades primárias. Nenhuma classe sequer existe. O protótipo de um objeto é apenas outro objeto ao qual o objeto está vinculado. Cada objeto tem um link de protótipo (e apenas um). Novos objetos podem ser criados com base em objetos já existentes escolhidos como seu protótipo. Você pode chamar dois objetos diferentes de maçã e laranja de fruta, se o objeto fruta existir, e tanto a maçã quanto a laranja tiverem fruta como seu protótipo. A ideia da classe fruta não existe explicitamente, mas como oclasse de equivalência dos objetos que compartilham o mesmo protótipo. Os atributos e métodos do protótipo são delegados a todos os objetos da classe de equivalência definida por este protótipo. Os atributos e métodos de propriedade individual do objeto não podem ser compartilhados por outros objetos da mesma classe de equivalência; por exemplo, o atributo sugar_content pode não estar presente inesperadamente em apple . Somente herança simples pode ser implementada por meio do protótipo.

Envio dinâmico/transmissão de mensagens

É responsabilidade do objeto, não de qualquer código externo, selecionar o código de procedimento a ser executado em resposta a uma chamada de método, normalmente procurando o método em tempo de execução em uma tabela associada ao objeto. Esse recurso é conhecido como despacho dinâmico . Se a variabilidade da chamada depende de mais do que um único tipo de objeto no qual ela é chamada (ou seja, pelo menos um outro objeto de parâmetro está envolvido na escolha do método), fala-se de despacho múltiplo .

Uma chamada de método também é conhecida como passagem de mensagens . Ele é conceituado como uma mensagem (o nome do método e seus parâmetros de entrada) sendo passado ao objeto para despacho.

Encapsulamento

Encapsulamento é um padrão de design no qual os dados são visíveis apenas para funções semanticamente relacionadas, de modo a evitar o uso indevido. O sucesso do encapsulamento de dados leva à frequente incorporação de ocultação de dados como princípio de design na programação funcional pura e orientada a objetos.

Se uma classe não permite que o código de chamada acesse dados de objetos internos e permite acesso apenas por meio de métodos, essa é uma forma forte de abstração ou ocultação de informações conhecida como encapsulamento . Algumas linguagens (Java, por exemplo) permitem que as classes imponham restrições de acesso explicitamente, por exemplo, denotando dados internos com a palavra- privatechave e designando métodos destinados ao uso por código fora da classe com a palavra- publicchave. Os métodos também podem ser projetados em níveis públicos, privados ou intermediários, como protected(que permite acesso da mesma classe e suas subclasses, mas não objetos de uma classe diferente). Em outras linguagens (como Python) isso é aplicado apenas por convenção (por exemplo, privateos métodos podem ter nomes que começam com um sublinhado). O encapsulamento evita que o código externo se preocupe com o funcionamento interno de um objeto. Isso facilita a refatoração de código , por exemplo, permitindo que o autor da classe altere como os objetos dessa classe representam seus dados internamente sem alterar nenhum código externo (desde que as chamadas de métodos "públicos" funcionem da mesma maneira). Ele também incentiva os programadores a colocar todo o código relacionado a um determinado conjunto de dados na mesma classe, o que o organiza para facilitar a compreensão por outros programadores. O encapsulamento é uma técnica que incentiva a dissociação .

Composição, herança e delegação

Os objetos podem conter outros objetos em suas variáveis ​​de instância; isso é conhecido como composição de objetos . Por exemplo, um objeto na classe Employee pode conter (diretamente ou por meio de um ponteiro) um objeto na classe Address, além de suas próprias variáveis ​​de instância como "first_name" e "position". A composição de objetos é usada para representar relacionamentos "tem-a": todo funcionário tem um endereço, portanto, cada objeto Employee tem acesso a um local para armazenar um objeto Address (diretamente incorporado a si mesmo ou em um local separado endereçado por um ponteiro) .

Linguagens que suportam classes quase sempre suportam herança. Isso permite que as classes sejam organizadas em uma hierarquia que represente relacionamentos "é um tipo de". Por exemplo, a classe Employee pode herdar da classe Person. Todos os dados e métodos disponíveis para a classe pai também aparecem na classe filha com os mesmos nomes. Por exemplo, a classe Person pode definir as variáveis ​​"first_name" e "last_name" com o método "make_full_name()". Estes também estarão disponíveis na classe Empregado, que poderá adicionar as variáveis ​​“cargo” e “salário”. Essa técnica permite a fácil reutilização dos mesmos procedimentos e definições de dados, além de potencialmente espelhar relacionamentos do mundo real de maneira intuitiva. Em vez de utilizar tabelas de banco de dados e sub-rotinas de programação, o desenvolvedor utiliza objetos com os quais o usuário pode estar mais familiarizado: objetos de seu domínio de aplicação. [21]

As subclasses podem substituir os métodos definidos pelas superclasses. A herança múltipla é permitida em alguns idiomas, embora isso possa tornar a resolução de substituições complicada. Algumas linguagens têm suporte especial para mixins , embora em qualquer linguagem com herança múltipla, um mixin é simplesmente uma classe que não representa um relacionamento é um tipo de. Mixins são normalmente usados ​​para adicionar os mesmos métodos a várias classes. Por exemplo, a classe UnicodeConversionMixin pode fornecer um método unicode_to_ascii() quando incluído na classe FileReader e na classe WebPageScraper, que não compartilham um pai comum.

Classes abstratas não podem ser instanciadas em objetos; eles existem apenas para fins de herança em outras classes "concretas" que podem ser instanciadas. Em Java, a palavra- finalchave pode ser usada para evitar que uma classe seja subclassificada.

A doutrina da composição sobre a herança defende a implementação de relacionamentos has-a usando composição em vez de herança. Por exemplo, em vez de herdar da classe Person, a classe Employee poderia dar a cada objeto Employee um objeto Person interno, que então teria a oportunidade de ocultar do código externo mesmo se a classe Person tivesse muitos atributos ou métodos públicos. Algumas linguagens, como Go , não suportam herança.

O " princípio aberto/fechado " defende que classes e funções "devem ser abertas para extensão, mas fechadas para modificação".

A delegação é outro recurso de linguagem que pode ser usado como alternativa à herança.

Polimorfismo

A subtipagem – uma forma de polimorfismo – é quando o código de chamada pode ser agnóstico em relação a qual classe na hierarquia suportada está operando – a classe pai ou um de seus descendentes. Enquanto isso, o mesmo nome de operação entre objetos em uma hierarquia de herança pode se comportar de maneira diferente.

Por exemplo, objetos do tipo Círculo e Quadrado são derivados de uma classe comum chamada Forma. A função Draw para cada tipo de Shape implementa o que é necessário para desenhar a si mesmo enquanto o código de chamada pode permanecer indiferente ao tipo específico de Shape que está sendo desenhado.

Esse é outro tipo de abstração que simplifica o código externo à hierarquia de classes e permite uma forte separação de interesses .

Abrir recursão

Em linguagens que suportam recursão aberta , métodos de objeto podem chamar outros métodos no mesmo objeto (incluindo eles mesmos), normalmente usando uma variável especial ou palavra-chave chamada thisou self. Essa variável é vinculada tardiamente ; ela permite que um método definido em uma classe invoque outro método que é definido posteriormente, em alguma subclasse da mesma.

Idiomas OOP

Simula (1967) é geralmente aceito como sendo a primeira linguagem com as características primárias de uma linguagem orientada a objetos. Ele foi criado para fazer programas de simulação , nos quais o que veio a ser chamado de objetos eram a representação da informação mais importante. Smalltalk (1972 a 1980) é outro exemplo inicial, e aquele com o qual grande parte da teoria de POO foi desenvolvida. Com relação ao grau de orientação a objetos, as seguintes distinções podem ser feitas:

OOP em linguagens dinâmicas

Nos últimos anos, a programação orientada a objetos tornou-se especialmente popular em linguagens de programação dinâmicas . Python , PowerShell , Ruby e Groovy são linguagens dinâmicas construídas com base em princípios OOP, enquanto Perl e PHP adicionam recursos orientados a objetos desde Perl 5 e PHP 4, e ColdFusion desde a versão 6.

O Document Object Model de documentos HTML , XHTML e XML na Internet tem ligações com a linguagem JavaScript / ECMAScript popular . JavaScript é talvez a linguagem de programação baseada em protótipo mais conhecida , que emprega a clonagem de protótipos em vez de herdar de uma classe (contraste com a programação baseada em classe ). Outra linguagem de script que adota essa abordagem é Lua .

OOP em um protocolo de rede

As mensagens que fluem entre computadores para solicitar serviços em um ambiente cliente-servidor podem ser projetadas como as linearizações de objetos definidos por objetos de classe conhecidos pelo cliente e pelo servidor. Por exemplo, um objeto linearizado simples consistiria em um campo de comprimento, um ponto de código identificando a classe e um valor de dados. Um exemplo mais complexo seria um comando que consiste no comprimento e ponto de código do comando e valores que consistem em objetos linearizados representando os parâmetros do comando. Cada um desses comandos deve ser direcionado pelo servidor para um objeto cuja classe (ou superclasse) reconheça o comando e seja capaz de fornecer o serviço solicitado. Clientes e servidores são melhor modelados como estruturas complexas orientadas a objetos. Arquitetura de gerenciamento de dados distribuídos(DDM) adotou essa abordagem e usou objetos de classe para definir objetos em quatro níveis de uma hierarquia formal:

  • Campos que definem os valores de dados que formam mensagens, como comprimento, ponto de código e valores de dados.
  • Objetos e coleções de objetos semelhantes ao que seria encontrado em um programa Smalltalk para mensagens e parâmetros.
  • Gerenciadores semelhantes ao IBM i Objects , como um diretório para arquivos e arquivos que consistem em metadados e registros. Os gerentes fornecem conceitualmente recursos de memória e processamento para seus objetos contidos.
  • Um cliente ou servidor composto por todos os gerenciadores necessários para implementar um ambiente de processamento completo, suportando aspectos como serviços de diretório, segurança e controle de concorrência.

A versão inicial dos serviços de arquivos distribuídos definidos pelo DDM. Mais tarde, foi estendido para ser a base da Arquitetura de Banco de Dados Relacional Distribuído (DRDA).

Padrões de design

Os desafios do projeto orientado a objetos são abordados por várias abordagens. O mais comum é conhecido como padrões de projeto codificados por Gamma et al. . Mais amplamente, o termo " padrões de projeto " pode ser usado para se referir a qualquer padrão de solução geral e repetível para um problema comum no projeto de software. Alguns desses problemas que ocorrem comumente têm implicações e soluções específicas para o desenvolvimento orientado a objetos.

Herança e subtipagem comportamental

É intuitivo supor que a herança cria um relacionamento semântico " é um " e, assim, inferir que objetos instanciados de subclasses sempre podem ser usados com segurança em vez daqueles instanciados da superclasse. Essa intuição infelizmente é falsa na maioria das linguagens OOP, em particular em todas aquelas que permitem objetos mutáveis . O polimorfismo de subtipo imposto pelo verificador de tipos em linguagens OOP (com objetos mutáveis) não pode garantir a subtipagem comportamentalem qualquer contexto. A subtipagem comportamental é indecidível em geral, portanto não pode ser implementada por um programa (compilador). As hierarquias de classes ou objetos devem ser cuidadosamente projetadas, considerando possíveis usos incorretos que não podem ser detectados sintaticamente. Este problema é conhecido como o princípio da substituição de Liskov .

Gang of Four padrões de design

Design Patterns: Elements of Reusable Object-Oriented Software é um livro influente publicado em 1994 por Erich Gamma , Richard Helm , Ralph Johnson e John Vlissides , muitas vezes referido humoristicamente como a "Gangue dos Quatro". Além de explorar os recursos e armadilhas da programação orientada a objetos, ele descreve 23 problemas comuns de programação e padrões para resolvê-los. Em abril de 2007, o livro estava em sua 36ª edição.

O livro descreve os seguintes padrões:

Orientação a objetos e bancos de dados

Tanto a programação orientada a objetos quanto os sistemas de gerenciamento de banco de dados relacional (RDBMSs) são extremamente comuns no software atual . Como os bancos de dados relacionais não armazenam objetos diretamente (embora alguns RDBMSs tenham recursos orientados a objetos para aproximar isso), há uma necessidade geral de unir os dois mundos. O problema de conectar acessos de programação orientada a objetos e padrões de dados com bancos de dados relacionais é conhecido como incompatibilidade de impedância objeto-relacional . Existem várias abordagens para lidar com esse problema, mas nenhuma solução geral sem desvantagens. [23] Uma das abordagens mais comuns é o mapeamento objeto-relacional , encontrado em linguagens IDE , comoVisual FoxPro e bibliotecas como Java Data Objects e Ruby on Rails ' ActiveRecord.

Existem também bancos de dados de objetos que podem ser usados ​​para substituir os RDBMSs, mas estes não tiveram tanto sucesso técnico e comercial quanto os RDBMSs.

Modelagem e relacionamentos do mundo real

OOP pode ser usado para associar objetos e processos do mundo real com contrapartes digitais. No entanto, nem todos concordam que a POO facilita o mapeamento direto do mundo real (consulte a seção Críticas ) ou que o mapeamento do mundo real é uma meta válida; Bertrand Meyer argumenta em Object-Oriented Software Construction [24] que um programa não é um modelo do mundo, mas um modelo de alguma parte do mundo; "A realidade é uma prima duas vezes removida". Ao mesmo tempo, algumas limitações principais da POO foram observadas. [25] Por exemplo, o problema círculo-elipse é difícil de lidar usando o conceito de herança da OOP .

No entanto, Niklaus Wirth (que popularizou o ditado agora conhecido como lei de Wirth : "O software está ficando mais lento mais rapidamente do que o hardware se torna mais rápido") disse sobre OOP em seu artigo, "Boas ideias através do espelho", "Este paradigma reflete de perto o estrutura de sistemas 'no mundo real' e, portanto, é adequado para modelar sistemas complexos com comportamentos complexos" [26] (contraste o princípio KISS ).

Steve Yegge e outros notaram que as linguagens naturais carecem da abordagem OOP de priorizar estritamente coisas (objetos/ substantivos ) antes de ações (métodos/ verbos ). [27] Este problema pode fazer com que a OOP sofra soluções mais complicadas do que a programação procedural. [28]

OOP e fluxo de controle

OOP foi desenvolvido para aumentar a capacidade de reutilização e manutenção do código-fonte. [29] A representação transparente do fluxo de controle não tinha prioridade e deveria ser tratada por um compilador. Com a crescente relevância do hardware paralelo e da codificação multithread , desenvolver um fluxo de controle transparente torna-se mais importante, algo difícil de alcançar com OOP. [30] [31] [32] [33]

Responsabilidade versus design orientado a dados

O design orientado por responsabilidade define as classes em termos de um contrato, ou seja, uma classe deve ser definida em torno de uma responsabilidade e das informações que ela compartilha. Isso é contrastado por Wirfs-Brock e Wilkerson com design orientado a dados , onde as classes são definidas em torno das estruturas de dados que devem ser mantidas. Os autores sustentam que o design orientado à responsabilidade é preferível.

Diretrizes SOLID e GRASP

SOLID é um mnemônico inventado por Michael Feathers que explica cinco princípios de design de engenharia de software:

GRASP (General Responsibility Assignment Software Patterns) é outro conjunto de diretrizes defendidas por Craig Larman .

Críticas

O paradigma OOP tem sido criticado por uma série de razões, incluindo não cumprir seus objetivos declarados de reusabilidade e modularidade, [34] [35] e por enfatizar demais um aspecto do projeto e modelagem de software (dados/objetos) em detrimento de outros aspectos importantes. aspectos (computação/algoritmos). [36] [37]

Luca Cardelli afirmou que o código OOP é "intrinsecamente menos eficiente" do que o código procedural, que OOP pode demorar mais para compilar e que as linguagens OOP têm "propriedades de modularidade extremamente pobres em relação à extensão e modificação de classe" e tendem a ser extremamente complexas . [34] O último ponto é reiterado por Joe Armstrong , o principal inventor do Erlang , que é citado como tendo dito: [35]

O problema com as linguagens orientadas a objetos é que elas têm todo esse ambiente implícito que carregam consigo. Você queria uma banana, mas o que você conseguiu foi um gorila segurando a banana e toda a selva.

Um estudo de Potok et al. não mostrou nenhuma diferença significativa na produtividade entre as abordagens OOP e procedimentais. [38]

Christopher J. Date afirmou que a comparação crítica de OOP com outras tecnologias, relacionais em particular, é difícil devido à falta de uma definição rigorosa e acordada de OOP; [39] no entanto, Date e Darwen propuseram uma base teórica sobre POO que usa OOP como um tipo de sistema de tipos personalizável para suportar RDBMS . [40]

Em um artigo, Lawrence Krubner afirmou que, em comparação com outras linguagens (dialetos LISP, linguagens funcionais, etc.), as linguagens OOP não têm pontos fortes únicos e infligem uma carga pesada de complexidade desnecessária. [41]

Alexander Stepanov compara orientação a objetos desfavoravelmente à programação genérica : [36]

Acho OOP tecnicamente infundado. Ele tenta decompor o mundo em termos de interfaces que variam em um único tipo. Para lidar com os problemas reais, você precisa de álgebras multiclassificadas — famílias de interfaces que abrangem vários tipos. Acho OOP filosoficamente infundado. Ele afirma que tudo é um objeto. Mesmo que seja verdade, não é muito interessante – dizer que tudo é um objeto não é dizer nada.

Paul Graham sugeriu que a popularidade da OOP dentro de grandes empresas se deve a "grandes (e frequentemente mudando) grupos de programadores medíocres". De acordo com Graham, a disciplina imposta pela OOP impede qualquer programador de "causar muito dano". [42]

Leo Brodie sugeriu uma conexão entre a natureza autônoma dos objetos e uma tendência a duplicar o código [43] em violação do princípio de não se repetir [44] do desenvolvimento de software.

Steve Yegge observou que, ao contrário da programação funcional : [45]

A Programação Orientada a Objetos coloca os substantivos em primeiro lugar. Por que você iria tão longe para colocar uma parte do discurso em um pedestal? Por que um tipo de conceito deve ter precedência sobre outro? Não é como se OOP de repente tornasse os verbos menos importantes na maneira como realmente pensamos. É uma perspectiva estranhamente distorcida.

Rich Hickey , criador do Clojure , descreveu os sistemas de objetos como modelos excessivamente simplistas do mundo real. Ele enfatizou a incapacidade da OOP de modelar o tempo adequadamente, o que está se tornando cada vez mais problemático à medida que os sistemas de software se tornam mais simultâneos. [37]

Eric S. Raymond , um programador Unix e defensor do software de código aberto , tem criticado as alegações que apresentam a programação orientada a objetos como a "Única Solução Verdadeira", e escreveu que as linguagens de programação orientadas a objetos tendem a encorajar programas em camadas espessas que destruir a transparência. [46] Raymond compara isso desfavoravelmente com a abordagem adotada com o Unix e a linguagem de programação C. [46]

Rob Pike , um programador envolvido na criação de UTF-8 e Go , chamou a programação orientada a objetos de "os algarismos romanos da computação" [47] e disse que as linguagens OOP frequentemente mudam o foco de estruturas de dados e algoritmos para tipos . [48] Além disso, ele cita um exemplo de um professor de Java cuja solução "idiomática" para um problema foi criar seis novas classes, em vez de simplesmente usar uma tabela de pesquisa . [49]

Semântica formal

Objetos são as entidades de tempo de execução em um sistema orientado a objetos. Eles podem representar uma pessoa, um lugar, uma conta bancária, uma tabela de dados ou qualquer item que o programa tenha que manipular.

Houve várias tentativas de formalizar os conceitos usados ​​na programação orientada a objetos. Os seguintes conceitos e construções foram usados ​​como interpretações dos conceitos de POO:

As tentativas de encontrar uma definição ou teoria de consenso por trás dos objetos não se mostraram muito bem-sucedidas (no entanto, consulte Abadi & Cardelli, A Theory of Objects [51] para definições formais de muitos conceitos e construções de POO) e muitas vezes divergem amplamente. Por exemplo, algumas definições se concentram nas atividades mentais e outras na estruturação do programa. Uma das definições mais simples é que OOP é o ato de usar estruturas de dados de "mapa" ou matrizes que podem conter funções e ponteiros para outros mapas, todos com algum açúcar sintático e de escopo no topo. A herança pode ser realizada clonando os mapas (às vezes chamado de "prototipagem").

Veja também

Sistemas

Linguagens de modelagem

Referências

  1. ^ Kindler, E.; Krivy, I. (2011). "Simulação orientada a objetos de sistemas com controle sofisticado". International Journal of General Systems: 313–343. {{cite journal}}:Cite journal requer |journal=( ajuda )
  2. ^ Lewis, João; Loftus, William (2008). Java Software Solutions Fundamentos do Design de Programação 6ª ed . Pearson Education Inc. ISBN 978-0-321-53205-3., seção 1.6 "Programação Orientada a Objetos"
  3. ^ McCarthy, J.; Brayton, R .; Edwards, D .; Fox, P .; Hodes, L .; Luckham, D .; Maling, K .; Parque, D. ; Russell, S. (março de 1960). "Manual de Programadores LISP I" (PDF) . Boston , Massachusetts : Grupo de Inteligência Artificial, Centro de Computação do MIT e Laboratório de Pesquisa: 88f. Arquivado a partir do original (PDF) em 17 de julho de 2010. No patois local do MIT, as listas de associações [de símbolos atômicos] também são chamadas de "listas de propriedades", e os símbolos atômicos às vezes são chamados de "objetos". {{cite journal}}:Cite journal requer |journal=( ajuda )
  4. ^ McCarthy, John ; Abrahams, Paul W.; Edwards, Daniel J .; Hart, swapnil d.; Levin, Michael I. (1962). Manual do programador LISP 1.5 . Imprensa do MIT . pág. 105 . ISBN 978-0-262-13011-0. Objeto — um sinônimo para símbolo atômico
  5. ^ a b "Dr. Alan Kay sobre o significado de "Programação Orientada a Objetos"" . 2003 . Recuperado em 11 de fevereiro de 2010 .
  6. ^ Sutherland, IE (30 de janeiro de 1963). "Sketchpad: Um Sistema de Comunicação Gráfica Homem-Máquina" . Relatório Técnico No. 296, Laboratório Lincoln, Instituto de Tecnologia de Massachusetts via Centro de Informações Técnicas de Defesa (stinet.dtic.mil) . Recuperado em 17 de julho de 2019 .
  7. ^ O Desenvolvimento das Línguas Simula, Kristen Nygaard , Ole-Johan Dahl , p.254 Uni-kl.ac.at
  8. ^ Ross, Douglas. "A primeira linguagem de engenharia de software" . Cronograma do Laboratório LCS/AI . Laboratório de Ciência da Computação e Inteligência Artificial do MIT . Recuperado em 13 de maio de 2010 .
  9. ^ a b Holmevik, Jan Rune (1994). "Compilando Simula: Um estudo histórico da gênese tecnológica" (PDF) . IEEE Annals of the History of Computing . 16 (4): 25–37. doi : 10.1109/85.329756 . S2CID 18148999 . Arquivado do original (PDF) em 30 de agosto de 2017 . Recuperado em 3 de março de 2018 .  
  10. ^ a b Bertrand Meyer (2009). Toque de classe: aprendendo a programar bem com objetos e contratos . Springer Science & Business Media. pág. 329. Bibcode : 2009tclp.book.....M . ISBN 978-3-540-92144-8.
  11. ^ Kay, Alan. "A história inicial do Smalltalk" . Arquivado a partir do original em 10 de julho de 2008 . Recuperado em 13 de setembro de 2007 .
  12. ^ 1995 (junho) Visual FoxPro 3.0, FoxPro evolui de uma linguagem procedural para uma linguagem orientada a objetos. O Visual FoxPro 3.0 apresenta um contêiner de banco de dados, recursos de cliente/servidor contínuos, suporte para tecnologias ActiveX e automação OLE e suporte a nulos. Resumo dos lançamentos da Fox
  13. ^ Site FoxPro History: Foxprohistory.org
  14. ^ Guia de revisores de 1995 para Visual FoxPro 3.0: DFpug.de
  15. ↑ Khurana, Rohit (1 de novembro de 2009). Programação Orientada a Objetos com C++, 1E . ISBN 978-81-259-2532-3.
  16. ^ Deborah J. Armstrong. Os Quarks do Desenvolvimento Orientado a Objetos . Uma pesquisa de quase 40 anos de literatura de computação que identificou uma série de conceitos fundamentais encontrados na grande maioria das definições de POO, em ordem decrescente de popularidade: Herança, Objeto, Classe, Encapsulamento, Método, Passagem de Mensagem, Polimorfismo e Abstração.
  17. ^ John C. Mitchell , Conceitos em linguagens de programação , Cambridge University Press, 2003, ISBN 0-521-78098-5 , p.278. Listas: Despacho dinâmico, abstração, polimorfismo de subtipo e herança. 
  18. ↑ Michael Lee Scott, Programming language pragmatics , Edição 2, Morgan Kaufmann, 2006, ISBN 0-12-633951-1 , p. 470. Lista encapsulamento, herança e despacho dinâmico. 
  19. ^ Pierce, Benjamin (2002). Tipos e Linguagens de Programação . Imprensa do MIT. ISBN 978-0-262-16209-8., seção 18.1 "O que é programação orientada a objetos?" Listas: Despacho dinâmico, encapsulamento ou multimétodos (despacho múltiplo), polimorfismo de subtipo, herança ou delegação, recursão aberta ("this"/"self")
  20. ^ Booch, Grady (1986). Engenharia de Software com Ada . Addison Wesley. pág. 220. ISBN 978-0-8053-0608-8. Talvez a maior força de uma abordagem de desenvolvimento orientada a objetos seja que ela oferece um mecanismo que captura um modelo do mundo real.
  21. ^ Jacobsen, Ivar; Magnus Christerson; Patrik Jonsson; Gunnar Overgaard (1992). Engenharia de Software Orientada a Objetos . Addison-Wesley ACM Press. págs.  43–69 . ISBN 978-0-201-54435-0.
  22. ^ "A linguagem de programação Emerald" . 26 de fevereiro de 2011.
  23. ↑ Neward, Ted (26 de junho de 2006). "O Vietnã da Ciência da Computação" . A interoperabilidade acontece. Arquivado a partir do original em 4 de julho de 2006 . Recuperado em 2 de junho de 2010 .
  24. ^ Meyer, segunda edição, p. 230
  25. ^ M.Trofimov, OOOP – A Terceira Solução "O": Abra OOP. Primeira Classe, OMG , 1993, Vol. 3, número 3, p.14.
  26. ^ Wirth, Nicklaus (2006). "Boas ideias, através do espelho" (PDF) . Computador . 39 (1): 28–39. doi : 10.1109/mc.2006.20 . S2CID 6582369 . Arquivado a partir do original (PDF) em 12 de outubro de 2016 . Recuperado em 2 de outubro de 2016 .  
  27. ^ Yegge, Steve (30 de março de 2006). "Execução no Reino dos Substantivos" . steve-yegge.blogspot.com . Recuperado em 3 de julho de 2010 .
  28. ↑ Boronczyk, Timothy (11 de junho de 2009). "O que há de errado com OOP" . zaemis.blogspot.com . Recuperado em 3 de julho de 2010 .
  29. ^ Ambler, Scott (1 de janeiro de 1998). "Um olhar realista sobre a reutilização orientada a objetos" . drdobbs . com . Recuperado em 4 de julho de 2010 .
  30. ↑ Shelly, Asaf (22 de agosto de 2008). "Falhas da Modelagem Orientada a Objetos" . Rede de software Intel . Recuperado em 4 de julho de 2010 .
  31. ^ James, Justin (1 de outubro de 2007). "Multithreading é um verbo, não um substantivo" . techrepublic. com. Arquivado a partir do original em 10 de outubro de 2007 . Recuperado em 4 de julho de 2010 .
  32. ↑ Shelly, Asaf (22 de agosto de 2008). "HOW TO: Multicore Programming (Multiprocessing) Visual C++ Class Design Guidelines, Member Functions" . support.microsoft . com . Recuperado em 4 de julho de 2010 .
  33. ^ Robert Harper (17 de abril de 2011). "Algumas reflexões sobre o ensino de PF" . Blog Tipo Existencial . Recuperado em 5 de dezembro de 2011 .
  34. ^ a b Cardelli, Luca (1996). "Propriedades de engenharia ruins de linguagens orientadas a objetos" . Computação ACM. Sobreviv . 28 (4es): 150–es. doi : 10.1145/242224.242415 . ISSN 0360-0300 . S2CID 12105785 . Recuperado em 21 de abril de 2010 .  
  35. ^ a b Armstrong, Joe. Em Coders at Work: Reflexões sobre o ofício de programação. Peter Seibel, ed. Codersatwork.com Arquivado em 5 de março de 2010 no Wayback Machine , acessado em 13 de novembro de 2009.
  36. ^ a b Stepanov, Alexandre . "STLport: Uma entrevista com A. Stepanov" . Recuperado em 21 de abril de 2010 .
  37. ^ a b Hickey rico, keynote 2009 da cimeira das línguas JVM, estamos nós lá ainda? novembro de 2009.
  38. ^ Potok, Thomas; Mladen Vouk; Andy Rindos (1999). "Análise de Produtividade de Software Orientado a Objetos Desenvolvido em Ambiente Comercial" (PDF) . Software – Prática e Experiência . 29 (10): 833-847. doi : 10.1002/(SICI)1097-024X(199908)29:10<833::AID-SPE258>3.0.CO;2-P . Recuperado em 21 de abril de 2010 .
  39. ^ CJ Data, Introdução aos Sistemas de Banco de Dados, 6ª edição., Página 650
  40. ^ Data de CJ, Hugh Darwen. Foundation for Future Database Systems: The Third Manifesto (2ª Edição)
  41. ^ Krubner, Lawrence. "Programação Orientada a Objetos é um desastre caro que deve acabar" . smashcompany. com. Arquivado a partir do original em 14 de outubro de 2014 . Recuperado em 14 de outubro de 2014 .
  42. ^ Graham, Paulo . "Por que o ARC não é especialmente orientado a objetos" . PaulGraham . com . Recuperado em 13 de novembro de 2009 .
  43. ^ Brodie, Leo (1984). Pensando Adiante (PDF) . págs. 92–93 . Recuperado em 4 de maio de 2018 .
  44. ^ Hunt, André. "Não se repita" . Categoria Programação Extrema . Recuperado em 4 de maio de 2018 .
  45. ^ "Blog de Stevey Rants: Execução no Reino dos Substantivos" . Recuperado em 20 de maio de 2020 .
  46. ^ a b Eric S. Raymond (2003). "A Arte da Programação Unix: Unix e Linguagens Orientadas a Objetos" . Recuperado em 6 de agosto de 2014 .
  47. ^ Pike, Rob (2 de março de 2004). "[9fans] Re: Tópicos: Costurar distintivos de honra em um Kernel" . comp.os.plan9 (Lista de discussão) . Recuperado em 17 de novembro de 2016 .
  48. ^ Pike, Rob (25 de junho de 2012). "Menos é exponencialmente mais" . Recuperado em 1 de outubro de 2016 .
  49. ^ Pike, Rob (14 de novembro de 2012). "Há alguns anos vi esta página" . Arquivado a partir do original em 14 de agosto de 2018 . Recuperado em 1 de outubro de 2016 .
  50. ^ Enquete, Erik. "Subtipagem e herança para tipos de dados categóricos" (PDF) . Recuperado em 5 de junho de 2011 .
  51. ^ a b Abadi, Martin ; Cardelli, Lucas (1996). Uma Teoria dos Objetos . Springer-Verlag Nova York, Inc. ISBN 978-0-387-94775-4. Recuperado em 21 de abril de 2010 .

Leitura adicional

Links externos

Recuperado de " https://en.wikipedia.org/w/index.php?title=Object-oriented_programming&oldid=1069227453 "
0.048611879348755