Programação Orientada a Objetos

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

Uma característica comum dos objetos é que os procedimentos (ou métodos) são anexados a eles e podem acessar e modificar os campos de dados do objeto. Nesta marca de OOP, geralmente há um nome especial como thisou selfusado para se referir ao objeto atual. Em OOP, 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 os objetos são instâncias de classes , que também determinam seus tipos .

Muitas das linguagens de programação mais amplamente utilizadas (como C++, Java [ 3 ] , Python , etc.)

Linguagens orientadas a objetos significativas incluem: Ada , ActionScript , C++ , Common Lisp , C# , Dart , Eiffel , Fortran 2003 , Haxe , Java [3] , JavaScript , Kotlin , logo , MATLAB , Objective-C , Object Pascal , Perl , PHP , Python , R , Raku , Ruby , Scala ,SIMSCRIPT , Simula , Smalltalk , Swift , Vala e Visual Basic.NET .

História

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

A terminologia invocando "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); [4] [5] Alan Kay posteriormente citou uma compreensão detalhada dos internos do LISP como uma forte influência em seu pensamento em 1966. [6]

Pensei em objetos como células biológicas e/ou computadores individuais em uma rede, capazes apenas de se comunicar com mensagens (então as mensagens vieram logo 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, [6]

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 Sketchpad, Sutherland definiu as noções de "objeto" e "instância" (com o conceito de classe coberto por "mestre" ou "definição"), embora especializado para interação gráfica. [7] Além disso, uma versão do MIT ALGOL , AED-0, estabeleceu uma ligação direta entre estruturas de dados ("plexos", naquele dialeto) e procedimentos, prefigurando o que mais tarde foi denominado "mensagens", "métodos" e "funções de membros ". [8] [9]

O Simula introduziu conceitos importantes que hoje são parte essencial da programação orientada a objetos, como classe e objeto , herança e vinculação dinâmica . [10] 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. [10]

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 incluía um ambiente de programação e era tipado dinamicamente , e a princípio era 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. [11] Enquanto Smalltalkfoi influenciado pelas ideias introduzidas no Simula 67, foi projetado para ser um sistema totalmente dinâmico no qual as classes podem ser criadas e modificadas dinamicamente. [12]

Na década de 1970, Smalltalk influenciou a comunidade Lisp a incorporar técnicas baseadas em objetos que foram introduzidas aos desenvolvedores por meio 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-object . Na década de 1980, houve algumas tentativas de projetar arquiteturas de processadores que incluíssem suporte de hardware para objetos na memória, mas não tiveram sucesso. Exemplos incluem oIntel iAPX 432 e 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 Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), que contou com a presença inesperada 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 o Simula para sua tese de doutorado, acabou criando o C++ orientado a objetos . [11] Em 1985, Bertrand Meyertambém produziu o primeiro desenho da linguagem Eiffel . Com foco 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 da 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 (verde) e o C processual (preto) competiram pela primeira posição.

No início e meados da década de 1990, a programação orientada a objetos se desenvolveu como o paradigma de programação dominante quando as linguagens de programação que suportavam as técnicas se tornaram amplamente disponíveis. Estes incluíram Visual FoxPro 3.0, [13] [14] [15] C++ , [16] e Delphi [ citação necessária ] . Seu domínio foi reforçado pela crescente popularidade das interfaces gráficas do usuário , que dependem fortemente de técnicas de programação orientada a objetos. Um exemplo de biblioteca de GUI dinâmica e linguagem OOP intimamente relacionada pode ser encontrado em Cocoa frameworks no Mac OS X , escrito emObjective-C , uma extensão de mensagens dinâmicas 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 esteja limitado a OOP).

Na ETH Zürich , Niklaus Wirth e seus colegas também investigaram 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 sucessor, Oberon , incluiu uma abordagem distinta para orientação a objetos, classes e outros.

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 também compatíveis com a metodologia procedural. Duas dessas linguagens são Python e Ruby . Provavelmente, as linguagens orientadas a objeto 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 uma dessas duas estruturas 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 que classes definidas em uma linguagem criem subclasses de classes definidas em 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 suportar OOP. Realiza operações sobre operandos. Os recursos listados abaixo são comuns entre linguagens consideradas fortemente orientadas a classes e objetos (ou multiparadigma com suporte OOP), com exceções notáveis ​​mencionadas. [17] [18] [19] [20]

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 compartilhe o mesmo nome em outro arquivo ou módulo.

Objetos e classes

As linguagens que oferecem suporte à programação orientada a objetos (OOP) geralmente 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 as funções de membro
  • Objetos – instâncias de classes

Às vezes, os objetos 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". [21] Às vezes, os 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 medições do padrão americano para métrico.

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 ; existe apenas uma cópia de cada variável, compartilhada por todas as instâncias da classe
  • 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 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 do 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 muitos idiomas, são efetivamente ponteiros , servindo como referências reais a 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 ao ser executado, que operam de forma independente. 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 classe , enquanto a programação baseada em protótipo normalmente não usa classes. Como resultado, uma terminologia significativamente diferente, mas 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 previamente e os objetos são instanciados com base nas classes. Se dois objetos maçã e laranja são instanciados da classe Fruta , eles são inerentemente frutas e é garantido que você pode manipulá-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. Não existem aulas . O protótipo de um objeto é apenas outro objeto ao qual o objeto está vinculado. Todo 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 protótipo. A ideia da classe das frutas não existe explicitamente, mas como aclasse 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 pertencentes individualmente ao 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 única pode ser implementada por meio do protótipo.

Despacho dinâmico/passagem de mensagem

É 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, geralmente 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 mensagem . Ele é conceituado como uma mensagem (o nome do método e seus parâmetros de entrada) sendo passada ao objeto para despacho.

Abstração de dados

A abstração de dados é 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 da abstração de dados leva à frequente incorporação da ocultação de dados como um 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 os dados do objeto interno e permite o acesso apenas por meio de métodos, essa é uma forma de ocultação de informações conhecida como abstração . Algumas linguagens (Java, por exemplo) permitem que as classes imponham restrições de acesso explicitamente, por exemplo, denotando dados internos com a privatepalavra-chave e designando métodos destinados ao uso por código fora da classe com a publicpalavra-chave. [22] Os métodos também podem ser projetados em níveis públicos, privados ou intermediários, como protected(que permite o acesso da mesma classe e suas subclasses, mas não objetos de uma classe diferente). [22] Em outras linguagens (como Python), isso é aplicado apenas por convenção (por exemplo, privatemétodos podem ter nomes que começam com umsublinhado ). Nas linguagens C#, Swift e Kotlin, internala palavra-chave permite acesso apenas aos arquivos presentes no mesmo assembly, pacote ou módulo da classe. [23]

Encapsulamento

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étodo "públicas" funcionem da mesma maneira). Também incentiva os programadores a colocar todo o código que diz respeito a um determinado conjunto de dados na mesma classe, que o organiza para facilitar a compreensão por outros programadores. O encapsulamento é uma técnica que encoraja o desacoplamento .

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 objeto . 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 objeto é usada para representar relacionamentos "tem um": todo funcionário tem um endereço, portanto, todo objeto Funcionário tem acesso a um local para armazenar um objeto Endereço (diretamente incorporado a si mesmo ou em um local separado endereçado por meio de um ponteiro) .

Linguagens que suportam classes quase sempre suportam herança. Isso permite que as classes sejam organizadas em uma hierarquia que representa relacionamentos "é um tipo de". Por exemplo, a classe Empregado pode herdar da classe Pessoa. 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 Funcionário, que poderá agregar 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 as relações 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. [24]

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. Alguns idiomas têm suporte especial para mixins , embora em qualquer idioma com herança múltipla, um mixin seja 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ída 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 finalpalavra-chave pode ser usada para evitar que uma classe seja subclasse. [25]

A doutrina de composição sobre herança defende a implementação de relacionamentos tem-um 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 teria a oportunidade de ocultar do código externo, mesmo que 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

Subtipagem – uma forma de polimorfismo – é quando o código de chamada pode ser independente de 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 Circle e Square são derivados de uma classe comum chamada Shape. 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 particular de Shape que está sendo desenhado.

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

Recursão aberta

Em linguagens que oferecem suporte à recursão aberta , os métodos de objeto podem chamar outros métodos no mesmo objeto (incluindo eles próprios), geralmente usando uma variável ou palavra-chave especial chamada thisou self. Esta variável é vinculada tardiamente ; permite que um método definido em uma classe invoque outro método definido posteriormente, em alguma subclasse dela.

Linguagens OOP

Simula (1967) é geralmente aceito como sendo a primeira linguagem com as principais características de uma linguagem orientada a objetos. Foi criado para fazer programas de simulação , nos quais o que veio a ser chamado de objetos eram as representações de informações mais importantes. Smalltalk (1972 a 1980) é outro exemplo inicial, e aquele com o qual grande parte da teoria da OOP 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 sobre princípios OOP, enquanto Perl e PHP vêm adicionando recursos orientados a objetos desde Perl 5 e PHP 4, e ColdFusion desde a versão 6.

O Modelo de Objeto de Documento de documentos HTML , XHTML e XML na Internet tem vínculos com a popular linguagem JavaScript / ECMAScript . 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 (em 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 linearizações de objetos definidos por objetos de classe conhecidos tanto pelo cliente quanto 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 no ponto de código do comando e valores que consistem em objetos linearizados que representam os parâmetros do comando. Cada um desses comandos deve ser direcionado pelo servidor a 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 as 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 do DDM definiu serviços de arquivos distribuídos. Posteriormente, foi estendido para ser a base da Distributed Relational Database Architecture (DRDA).

Padrões de design

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

Herança e subtipagem comportamental

É intuitivo assumir que a herança cria um relacionamento semântico " é um " e, assim, inferir que os objetos instanciados de subclasses sempre podem ser usados ​​com segurança em vez daqueles instanciados da superclasse. Infelizmente, essa intuição é falsa na maioria das linguagens OOP, em particular naquelas que permitem objetos mutáveis . O polimorfismo de subtipos 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). Hierarquias de classes ou objetos devem ser cuidadosamente projetadas, considerando possíveis usos incorretos que não podem ser detectados sintaticamente. Esta questão é conhecida como o princípio da substituição de Liskov .

Padrões de design da Gangue dos Quatro

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 com humor como a "Gangue dos Quatro". Além de explorar as capacidades 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 atualmente . 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. [27] Uma das abordagens mais comuns é o mapeamento objeto-relacional , como 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 RDBMSs, mas eles não têm sido tão bem-sucedidos técnica e comercialmente 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 OOP facilita o mapeamento direto do mundo real (consulte a seção Críticas) ou que o mapeamento do mundo real seja um objetivo digno; Bertrand Meyer argumenta em Object-Oriented Software Construction [28] que um programa não é um modelo do mundo, mas um modelo de alguma parte do mundo; "A realidade é uma prima duas vezes afastada". Ao mesmo tempo, algumas limitações principais da OOP foram observadas. [29] Por exemplo, o problema da elipse circular é difícil de lidar usando o conceito de herança 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 fica 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" [30] (compare o princípio KISS ).

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

OOP e fluxo de controle

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

Responsabilidade vs. design baseado em dados

O design orientado à 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 baseado em responsabilidade é preferível.

Diretrizes SOLID e GRASP

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

GRASP (Padrões de Software de Atribuição de Responsabilidade Geral) é outro conjunto de diretrizes defendidas por Craig Larman .

Crítica

O paradigma OOP tem sido criticado por uma série de razões, incluindo não atingir seus objetivos declarados de reutilização e modularidade, [38] [39] e por enfatizar demais um aspecto do design e modelagem de software (dados/objetos) em detrimento de outros aspectos importantes. aspectos (computação/algoritmos). [40] [41]

Luca Cardelli afirmou que o código OOP é "intrinsecamente menos eficiente" do que o código procedural, que o OOP pode levar mais tempo 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 . [38] O último ponto é reiterado por Joe Armstrong , o principal inventor do Erlang , que é citado como tendo dito: [39]

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 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 OOP e abordagens procedimentais. [42]

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 consensual de OOP; [43] no entanto, Date e Darwen propuseram um fundamento teórico sobre OOP que usa OOP como um tipo de sistema de tipos personalizável para suportar RDBMS . [44]

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 um fardo pesado de complexidade desnecessária. [45]

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

Acho OOP tecnicamente inseguro. 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 doentio. Ela 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 das grandes empresas se deve a "grandes (e frequentemente em mudança) grupos de programadores medíocres". De acordo com Graham, a disciplina imposta pela OOP evita que qualquer programador "cause muito dano". [46]

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

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

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 de 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 concorrentes. [41]

Eric S. Raymond , um programador Unix e defensor do software de código aberto , criticou as alegações de 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. [50] Raymond compara isso desfavoravelmente com a abordagem adotada com o Unix e a linguagem de programação C. [50]

Rob Pike , um programador envolvido na criação de UTF-8 e Go , chamou a programação orientada a objetos de "os numerais romanos da computação" [51] e disse que as linguagens OOP freqüentemente mudam o foco de estruturas de dados e algoritmos para tipos . [52] Além disso, ele cita o 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 consulta . [53]

Com relação à herança, Bob Martin afirma que, por serem softwares, as classes relacionadas não compartilham necessariamente os relacionamentos das coisas que representam. [54]

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 com o qual o programa tenha que lidar.

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 OOP:

As tentativas de encontrar uma definição ou teoria consensual por trás dos objetos não se mostraram muito bem-sucedidas (no entanto, consulte Abadi & Cardelli, A Theory of Objects [ 56] para definições formais de muitos conceitos e construções OOP) e geralmente divergem amplamente. Por exemplo, algumas definições se concentram em 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 arrays que podem conter funções e ponteiros para outros mapas, todos com um pouco de açúcar sintático e de escopo . 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". Jornal Internacional de Sistemas Gerais: 313–343. {{cite journal}}: Citar periódico requer |journal=( ajuda )
  2. ^ Lewis, John; LOFTUS, William (2008). Soluções de Software Java 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. ^ ab Bloch 2018, pp. xi–xii, Prefácio.
  4. ^ McCarthy, J.; Brayton, R.; Edwards, D.; Fox, P. ; Hodes, L. ; Luckham, D .; Maling, K.; Parque, D. ; Russell, S. (março de 1969). "Lisp I Programmers Manual" (PDF) . Boston , Massachusetts : Grupo de Inteligência Artificial, Centro de Computação e Laboratório de Pesquisa do MIT: 88f. Arquivado do original (PDF) em 17 de julho de 2010. No dialeto local do MIT, as listas de associação [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}}: Citar periódico requer |journal=( ajuda )
  5. ^ McCarthy, John ; Abrahams, Paul W.; Edwards, Daniel J.; Hart, swapnil d.; Levin, Michael I. (1962). LISP 1.5 Manual do Programador. MIT Pressione . pág. 105. ISBN 978-0-262-13011-0. Objeto — sinônimo de símbolo atômico
  6. ^ ab "Dr. Alan Kay sobre o significado de "Programação Orientada a Objetos"". 2003 . Consultado em 11 de fevereiro de 2010 .
  7. ^ 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). Arquivado do original em 8 de abril de 2013 . Acesso em 17 de julho de 2019 .
  8. ^ O desenvolvimento das línguas Simula, Kristen Nygaard , Ole-Johan Dahl , p.254 Uni-kl.ac.at
  9. ^ Ross, Douglas. "A primeira linguagem de engenharia de software". Linha do tempo do laboratório LCS/AI . Laboratório de Ciência da Computação e Inteligência Artificial do MIT . Consultado em 13 de maio de 2010 .
  10. ^ ab Holmevik, Jan Rune (1994). "Compiling 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 . Acesso em 3 de março de 2018 .
  11. ^ ab Bertrand Meyer (2009). Toque de Aula: 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.
  12. ^ Kay, Alan. "A história inicial de Smalltalk". Arquivado do original em 10 de julho de 2008 . Consultado em 13 de setembro de 2007 .
  13. ^ 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 integrados de cliente/servidor, suporte para tecnologias ActiveX e automação OLE e suporte nulo. Resumo dos lançamentos da Fox
  14. ^ Site da FoxPro History: Foxprohistory.org
  15. ^ Guia de revisores de 1995 para Visual FoxPro 3.0: DFpug.de
  16. ^ Khurana, Rohit (1 de novembro de 2009). Programação Orientada a Objetos com C++, 1E. ISBN 978-81-259-2532-3.
  17. ^ 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 Mensagens, Polimorfismo e Abstração.
  18. ^ 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. 
  19. Michael Lee Scott, Programming language pragmatics , Edition 2, Morgan Kaufmann, 2006, ISBN 0-12-633951-1 , p. 470. Lista encapsulamento, herança e despacho dinâmico. 
  20. ^ Pierce, Benjamin (2002). Tipos e linguagens de programação . Imprensa 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 subtipos, herança ou delegação, recursão aberta ("this"/"self")
  21. ^ 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.
  22. ^ ab Bloch 2018, pp. 73–77, Capítulo §4 Item15 Minimize a acessibilidade de classes e membros.
  23. ^ "O que é Programação Orientada a Objetos (OOP) em palavras simples? - Software Geek Bytes" . 5 de janeiro de 2023 . Acesso em 17 de janeiro de 2023 .
  24. ^ Jacobsen, Ivar; Magnus Christerson; Patrick Jonsson; Gunnar Overgaard (1992). Engenharia de Software Orientada a Objetos. Addison-Wesley ACM Press. pp. 43–69. ISBN 978-0-201-54435-0.
  25. ^ Bloch 2018, pág. 19, Capítulo §2 Item 4 Impor não instanciabilidade com um construtor privado.
  26. ^ "A linguagem de programação Emerald" . 26 de fevereiro de 2011.
  27. ^ Neward, Ted (26 de junho de 2006). "O Vietnã da Ciência da Computação". A interoperabilidade acontece. Arquivado do original em 4 de julho de 2006 . Consultado em 2 de junho de 2010 .
  28. ^ Meyer, segunda edição, p. 230
  29. ^ M.Trofimov, OOOP – A Terceira Solução "O": Open OOP. Primeira Classe, OMG , 1993, vol. 3, número 3, p.14.
  30. ^ Wirth, Nicklaus (2006). "Boas ideias, através do espelho" (PDF) . Computador . 39 (1): 28–39. doi : 10.1109/mc.2006.20. S2CID  6582369. Arquivado do original (PDF) em 12 de outubro de 2016 . Acesso em 2 de outubro de 2016 .
  31. ^ Yegge, Steve (30 de março de 2006). "Execução no Reino dos Substantivos". steve-yegge.blogspot.com . Consultado em 3 de julho de 2010 .
  32. ^ Boronczyk, Timothy (11 de junho de 2009). "O que há de errado com OOP" . zaemis.blogspot.com . Consultado em 3 de julho de 2010 .
  33. ^ Ambler, Scott (1 de janeiro de 1998). "Uma visão realista da reutilização orientada a objetos". drdobbs. com . Consultado em 4 de julho de 2010 .
  34. ^ Shelly, Asaf (22 de agosto de 2008). "Falhas da Modelagem Orientada a Objetos". Rede de Software Intel . Consultado em 4 de julho de 2010 .
  35. ^ James, Justin (1 de outubro de 2007). "Multithreading é um verbo, não um substantivo". techrepublic. com. Arquivado do original em 10 de outubro de 2007 . Consultado em 4 de julho de 2010 .
  36. ^ Shelly, Asaf (22 de agosto de 2008). "COMO: Programação Multicore (Multiprocessamento) Diretrizes de Design de Classe Visual C++, Funções de Membro". support.microsoft.com . Consultado em 4 de julho de 2010 .
  37. ^ Robert Harper (17 de abril de 2011). "Algumas reflexões sobre o ensino de FP". Blog Tipo Existencial . Consultado em 5 de dezembro de 2011 .
  38. ^ ab Cardelli, Luca (1996). "Propriedades de engenharia ruins de linguagens orientadas a objetos". Computação ACM. Sobreviver . 28 (4es): 150-es. doi : 10.1145/242224.242415. ISSN  0360-0300. S2CID  12105785 . Consultado em 21 de abril de 2010 .
  39. ^ ab Armstrong, Joe. Em Coders at Work: Reflexões sobre o ofício da 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.
  40. ^ ab Stepanov, Alexander . "STLport: Uma entrevista com A. Stepanov" . Consultado em 21 de abril de 2010 .
  41. ^ ab Rich Hickey, palestra principal do JVM Languages ​​Summit 2009, Are We There Yet? novembro de 2009.
  42. ^ 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. S2CID  57865731 . Consultado em 21 de abril de 2010 .
  43. ^ CJ Date, Introdução aos sistemas de banco de dados, 6ª ed., Página 650
  44. ^ Data de CJ, Hugh Darwen. Fundação para futuros sistemas de banco de dados: o terceiro manifesto (2ª edição)
  45. ^ Krubner, Lawrence. "Programação Orientada a Objetos é um desastre caro que deve acabar". smashcompany. com. Arquivado do original em 14 de outubro de 2014 . Acesso em 14 de outubro de 2014 .
  46. ^ Graham, Paul . "Por que o ARC não é especialmente orientado a objetos". PaulGraham. com . Consultado em 13 de novembro de 2009 .
  47. ^ Brodie, Leo (1984). Pensando adiante (PDF) . págs. 92–93 . Acesso em 4 de maio de 2018 .
  48. ^ Hunt, André. "Não se repita". Categoria Extreme Programming . Acesso em 4 de maio de 2018 .
  49. ^ "Blog de Steve: Execução no Reino dos Substantivos" . Acesso em 20 de maio de 2020 .
  50. ^ ab Eric S. Raymond (2003). "A Arte da Programação Unix: Unix e Linguagens Orientadas a Objetos" . Acesso em 6 de agosto de 2014 .
  51. ^ Pike, Rob (2 de março de 2004). "[9fans] Re: Tópicos: Costurando distintivos de honra em um Kernel" . comp.os.plan9 (Mailing list) . Acesso em 17 de novembro de 2016 .
  52. ^ Pike, Rob (25 de junho de 2012). "Menos é exponencialmente mais" . Acesso em 1 de outubro de 2016 .
  53. ^ Pike, Rob (14 de novembro de 2012). "Alguns anos atrás eu vi esta página". Arquivado do original em 14 de agosto de 2018 . Acesso em 1 de outubro de 2016 .
  54. ^ "Princípios Uncle Bob SOLID" . YouTube .
  55. ^ Enquete, Erik. "Subtipagem e herança para tipos de dados categóricos" (PDF) . Consultado em 5 de junho de 2011 .
  56. ^ ab Abadi, Martin ; Cardelli, Luca (1996). Uma Teoria dos Objetos. Springer-Verlag New York, Inc. ISBN 978-0-387-94775-4. Consultado em 21 de abril de 2010 .

Leitura adicional

links externos

  • Introdução aos conceitos de programação orientada a objetos (OOP) e mais por LWC Nirosh
  • Discussão sobre Contras de OOP
  • Conceitos OOP (tutoriais de Java)