Não, de jeito nenhum.
No entanto, é uma metodologia que permite criar uma boa abstração para manter estruturas de dados complexas, juntamente com alguns métodos que atuam nas estruturas de dados.
Eu já vi isso comumente repetido a programação orientada a objeto é baseada na modelagem do mundo real, mas é?
Parece-me que não é verdade em nada fora da camada de negócios. Minhas aulas de GUI / classes de acesso a dados não estão modelando nada no mundo real. Mesmo na minha camada de negócios, tenho aulas como observadores, gerentes, fábricas, etc., que não são objetos do mundo real. Eu tento projetar minhas aulas para aproveitar coisas como o encapsulamento, mas o mundo real é encapsulado?
Enquanto alguns objetos que crio estão modelando objetos do mundo real, o código pré-OOP não faria o mesmo? Duvido que a OO tenha sido a primeira pessoa a incluir conceitos como Customer em suas bases de código. Mas OO é realmente sobre como modelar as coisas, e esse método de modelagem não parece inspirado no mundo real para mim.
Então: a programação orientada a objetos realmente modela o mundo real?
Não, de jeito nenhum.
No entanto, é uma metodologia que permite criar uma boa abstração para manter estruturas de dados complexas, juntamente com alguns métodos que atuam nas estruturas de dados.
Modelos de qualquer tipo não modelam o mundo real, nem inteiramente.
Eles modelam as porções selecionadas , aquelas que são relevantes para o aplicativo em questão.
O que você está falando (observadores, gerentes, fábricas, etc ...) é a infraestrutura que está lá para ajudá-lo a obter a abstração correta e suportar as funções necessárias, como a persistência.
O que é um modelo, de qualquer maneira:
Um modelo é uma representação simplificada usada para explicar o funcionamento de um sistema ou evento do mundo real
Does object oriented programming allow you to model the real world?
Definitivamente SIM
É quase impossível modelar o sistema para corresponder exatamente ao mundo real.
Do I always have to model the software exactly after the real world?
NÃO
Tendo dito que você pode modelar tudo, não significa que você precise modelar tudo. De fato, a essência da modelagem útil é apresentar uma representação simplificada. Quanta simplificação é suficiente para expressar a necessidade atual do negócio, e o que precisa ser omitido, é um bom equilíbrio entre usar a técnica com sucesso versus se perder com ela ou não usá-la.
Existem, é claro, entidades que realmente não existem, mas somente através da modelagem podemos realmente conceituar bem.
Acho que ensinar que existe uma relação entre substantivos e classes faz com que se desenvolvam maus hábitos irritantes que precisam ser esmagados mais tarde por um arquiteto ou engenheiro sênior impaciente.
O que deve ser ensinado é que as classes modelam objetos abstratos, assim como o seu cérebro faz. Você tem um conceito abstrato de "carro" em sua cabeça que não mapeia para nenhum carro físico particular, é reutilizável, implementações específicas de carro podem herdar dele. Seu cérebro até mesmo modela conceitos para você. Você tem um modelo mental do que é pensamento, o que é um conceito.
Se ensinássemos às pessoas para identificar os modelos que elas já estão gerando em sua cabeça, elas estariam muito mais bem preparadas para criar um software real.
...The world is richer than what can be expressed with object-oriented syntax.
Consider a few common concepts that people universally use to understand and describe all systems – concepts that do not fit the object mold. The 'before/after' paradigm, as well that of 'cause/effect', and the notion of the 'state of the system' are amongst the most vivid examples. Indeed, the process of 'brewing coffee', or 'assembling a vehicle', or 'landing a rover on Mars' cannot be decomposed into simple objects. Yes, they are being treated that way in OO languages, but that's contrived and counter-intuitive. The sequence of the routine itself – what comes before what under what conditions based on what causality – simply has no meaningful representation in OO, because OO has no concept of sequencing, or state, or cause.
Processes are extremely common in the real world and in programming. Elaborate mechanisms have been devised over the years to handle transactions, workflow, orchestration, threads, protocols, and other inherently 'procedural' concepts. Those mechanisms breed complexity as they try to compensate for the inherent time-invariant deficiency in OO programming. Instead, the problem should be addressed at the root by allowing process-specific constructs, such as 'before/after', 'cause/effect', and, perhaps, 'system state' to be a core part of the language...
citar fonte: Victoria Livschitz, Próximo passo na programação
Sim, OO geralmente pode ser usado para modelar entidades do mundo real.
Even in my business layer I've got classes like observers, managers, factories, etc. which aren't real world objects.
Não confunda desenvolvimento orientado a objetos com padrões de design. OO análise e design é um meio para abordar código sustentável de programação. Juntamente com uma linguagem OO, os programadores têm o poder de criar código reutilizável por meio dos pilares OO: encapsulamento, polimorfismo e herança.
Para encapsular uma entidade, podemos modelar essa entidade após sua contraparte do mundo real. Por exemplo, se temos uma guitarra, então uma classe de guitarra encapsula os comportamentos e propriedades de uma guitarra do mundo real. Podemos ainda abstrair o violão como, digamos, um IInventoryItem para aproveitar o potencial de reutilização de código por meio de polimorfismo e herança.
Por outro lado, podemos descobrir que uma fábrica de guitarras pode nos ajudar a manter um conjunto de diferentes tipos de guitarras. Isso não é por causa do OO. Em vez disso, uma fábrica é um padrão de projeto que passou pelo teste do tempo como um meio comprovado de criar com sucesso um código de manutenção para esse fim. Em outras palavras, nós, programadores, estamos frequentemente resolvendo problemas semelhantes. Então, nós criamos uma solução comum para resolvê-los (não reinventar a roda).
Isso não significa que a OO tenha que modelar o mundo real, nem que seja sempre a melhor solução para fazê-lo. Simplesmente, que, como regra geral, "OO modelando o mundo real" faz todo o sentido.
While some objects I create are modelling real world objects, would not pre-OOP code do the same?
Eu diria que não. OOP relaciona o relacionamento entre as coisas (propriedades / objetos) e o que eles podem fazer / pode ser feito com eles (métodos), enquanto a programação procedural não faz isso (além de, em um pequeno grau, quando se usa digitação estrita). Um modelo não é apenas definir peças e processos discretos, mas também definir como eles se encaixam, e a OOP é particularmente boa nisso.
Depende de qual mundo real você está falando.
Jorge Luis Borges escreveu uma história "Tlön, Uqbar, Orbis Tertius", onde um dos povos habitantes parece perceber seu mundo real de maneira bem diferente:
[...] the people of the imaginary Tlön [...] hold an extreme form of Berkeleian idealism, denying the reality of the world. Their world is understood "not as a concurrence of objects in space, but as a heterogeneous series of independent acts." One of the imagined languages of Tlön lacks nouns. Its central units are "impersonal verbs qualified by monosyllabic suffixes or prefixes which have the force of adverbs." Borges lists a Tlönic equivalent of "The moon rose above the water": hlör u fang axaxaxas mlö, meaning literally "Upward behind the onstreaming it mooned". [...] In another language of Tlön, "the basic unit is not the verb, but the monosyllabic adjective," which, in combinations of two or more, are noun-forming: "moon" becomes "round airy-light on dark" or "pale-orange-of-the-sky.(copied from the wikipedia artice about the book)
Para mim, o ponto não é tanto que o mundo possa ser percebido diferentemente do que nós, o que é meio clichê, mas que a percepção da estrutura da realidade depende da linguagem que falamos, seja natural ou linguagem de programação. O Tlönese pode estar muito feliz com o Lisp, e pode ver o Java (AKA The Kingdom Of Nouns (Reino dos Substantivos) como muito antinatural, enquanto a maioria dos programadores terranos tendem a favorecer a orientação a objetos sobre linguagens funcionais. Eu gosto dos dois estilos, pois acho que é principalmente uma questão de perspectiva. Alguns problemas são melhor atacados com funcionalidades, outros com técnicas de programação orientada a objetos. Um bom programador sempre olha para um problema difícil de diferentes ângulos, antes de tentar uma solução. Ou, como Alan Kay colocou: Ponto de vista vale 80 pontos de QI .
Então, minha resposta para sua pergunta é: De qual mundo real você está falando? E como?
I've seen it commonly repeated the object oriented programming is based on modelling the real world, but is it?
Sim. A ênfase aqui é baseada em . OOP não modela o mundo real (se é que, aliás, incidentalmente) e não é suposto. O que a POO faz é nos permitir modelar problemas de programação da maneira como modelamos o mundo real: como um sistema de entidades que são definidas através de nossa abstração de seu comportamento.
O código OO geralmente não modela o mundo real - pelo menos esse não é o objetivo, ele simplesmente permite que você pense sobre o seu código de uma maneira mais natural, mais parecida com a maneira como você pensa sobre as coisas no real mundo - é isso que a citação está tentando dizer.
Não modela o nosso mundo, mas sim modela a interpretação humana do nosso mundo. Os seres humanos naturalmente separam as coisas como objetos. OO é eficaz porque permite que os humanos programem a maneira como pensam.
OOP pode não ser um modelo perfeito do mundo real e dos objetos contidos nele, mas é uma metodologia que ajuda a lidar com a crescente complexidade do software da vida real. Também ajuda a escrever melhor o código, dividindo-o em partes logicamente relacionadas.
Embora os métodos mais antigos orientados a procedimentos também forneçam resultados, a OOP ajuda você a chegar lá com mais rapidez e relativa facilidade, mesmo ao lidar com grandes & projetos complexos.
A abstração e o encapsulamento ajudam a concentrar-se no núcleo do problema, ocultando todo o encanamento que realmente faz as coisas acontecerem. Herança e permite estabelecer um relacionamento significativo e lógico entre vários aspectos do seu código. O polimorfismo promove a reutilização de código e permite lidar facilmente com variações (o comportamento "quase igual a um objeto existente" de problemas que ocorrem com tanta frequência) e estender o código estendendo a semântica associada a um objeto.
Eu sinto que a OOP é mais como uma ajuda comprovada que permite lidar com todas as complexidades de um sistema da vida real de maneira efetiva. Então, embora possa não ser um modelo muito completo do mundo real, ele está perto o suficiente e ajuda você a fazer as coisas, o que IMHO é tudo o que importa no final.
I've seen it commonly repeated the object oriented programming is based on modelling the real world, but is it?
It seems to me that is not true of anything outside of the business layer.
Não. Como você aponta, muitas das coisas "modeladas" em uma linguagem OOP são conceitos abstratos, como filas de mensagens e controladores e pilhas.
Mesmo em sua camada de negócios, você ainda não está modelando "o mundo real". Suponha que você tenha uma classe de funcionários. Os funcionários também são pessoas, que também são mamíferos, que também são animais, que também são… (bocejo) Os funcionários têm cores favoritas, usam roupas e acreditam em certas coisas. Em suma, há uma enorme variedade de complexidade no mundo real que nem tentamos capturar na maioria dos programas.
Na modelagem, nos concentramos apenas nos aspectos do modelo que são significativos para a tarefa em questão. Se estivermos projetando um sistema de entrada de horas, provavelmente queremos algum tipo de classe Employee, mas essa classe não precisa de uma propriedade para expressar a cor favorita do funcionário.
Portanto, os modelos não devem tentar (ou fingir) representar completamente o "mundo real".
While some objects I create are modelling real world objects, would not pre-OOP code do the same? I doubt that OO was the first people to include concepts like Customer in their code bases.
Você está correto. Se você observar programas grandes que não são OOP, eles ainda estarão organizados em torno de estruturas de dados. Uma estrutura de dados e todas as funções que manipulam são definidas próximas umas das outras, por motivos de clareza. (O projeto do subversion é um bom exemplo disso. Estruturas e funções de dados são prefixadas com nomes de módulos que está claro quais estruturas e funções devem ser usadas umas com as outras.)
Não sou especialista na história das linguagens de programação, mas imagino que a OOP surgiu da observação casual de que o código era mais claro e mais fácil de entender quando organizado dessa maneira, então os designers de linguagem começaram a projetar linguagens onde esse tipo de organização foi mais rigorosamente aplicada.
A maior diferença entre OOP e não OOP é que o OOP associa código a dados. Então, ao invés de chamar o código assim:
verb(noun);
fazemos isso em vez disso:
noun->verb();
Embora isso possa parecer uma diferença gramatical, a diferença está realmente em mente. Dizemos aos objetos o que fazer e, normalmente, não nos importamos com o estado interno ou o funcionamento do objeto. Ao descrever um objeto, precisamos apenas descrever sua interface pública para trabalhar com ele.
Does Object Oriented Programming Really Model The Real World?
Não completamente.
Bem no mundo real, enfrentamos problemas reais. Desejamos resolver este problema usando um paradigma que replica o sistema que desejamos construir, que se torna o modelo.
Por exemplo, se um aplicativo de carrinho de compras era o problema em questão, temos entidades diferentes, como
Produto , que é um termo abstrato que pode ter vários membros, como Livros, Gadgets, Carros, que podem ser subdivididos novamente.
Critérios fiscais como (Imposto sobre vendas) dependeriam de qual local o software é implementado, pois está sujeito a alterações com base nas políticas do governo.
Imposto é considerado com base no fato de o produto ter sido importado junto com os critérios fiscais.
O usuário pode ter um carrinho de compras que tenha uma lista de produtos, etc.
Então, como você pode ver, há problemas reais que estamos tentando resolver, mas modularizados para o paradigma da OOP, para torná-lo o mais próximo possível do sistema real.
Eu acho que você está lendo demais em uma declaração muito prosaica e histórica. Muitas das idéias de programação OO, classes, polimorfismo, funções virtuais, etc. foram introduzidas na linguagem Simula, na década de 1960 (http://en.wikipedia.org/wiki/Simula). Como o nome sugere, Simula foi projetado para ser uma linguagem para escrever simulações. Então, historicamente, sim, idéias OO foram introduzidas em um esforço para modelar o "mundo real". Se eles conseguem mais do que outros estilos é uma questão de debate.
While some objects I create are modelling real world objects, would not pre-OOP code do the same?
A maior diferença entre OOP e código pré-OOP é que o primeiro modela uma situação do mundo real como um grupo de entidades distintas interagindo umas com as outras, cada uma com "poder" limitado em relação ao que pode fazer e também capaz de " reagir "a eventos externos com ações próprias. Este último modela tudo como uma grande quantidade de dados que não fazem nada por si só, enquanto o cálculo representa "coisas que acontecem" e podem afetar qualquer um ou todos eles.
Se é melhor modelar o mundo real ou não, isso realmente depende de quais facetas do mundo você está modelando. Uma simulação física, por exemplo, onde você quer descrever os efeitos que, digamos, um fogo aceso teria nos objetos circundantes, seria melhor representado por uma abordagem "tradicional", uma vez que tanto a luz quanto o calor são bem- processos definidos que afetam o estado externo e interno de outros objetos e não variam de acordo com o comportamento de cada objeto específico, sendo afetados apenas por suas propriedades.
Por outro lado, se você estiver modelando componentes diferentes que interagem para produzir o comportamento desejado, tratá-los como agentes em vez de coisas passivas pode facilitar a execução correta sem perder nada. Se eu quiser ligar minha TV, basta pressionar o botão, se o cabo de energia estiver desconectado, o TV.turnOn irá verificar isso para mim. Portanto, não há risco de girar uma engrenagem e esquecer de girar a outra que está tocando nela, pois a própria engrenagem (se programada corretamente) cuidará das interações secundárias que vêm como consequência da principal.
But OO is really about how to model things, and that method of modelling doesn't seem inspired by the real world to me.
Eu acredito que tem mais a ver com a maneira como nós percebemos o mundo do que como o mundo realmente é. Pode-se argumentar que tudo é apenas um monte de átomos (ou energia, ou ondas, seja qual for), mas isso não nos ajuda a lidar com os problemas que enfrentamos, com a compreensão do ambiente ao nosso redor e a previsão de eventos futuros ( ou descrevendo os anteriores). Assim, fazemos "modelos mentais" do mundo, e muitas vezes esses modelos mentais encontram uma correspondência melhor com OO do que os dados + processam um - o que indiscutivelmente modela "melhor" como o mundo real realmente funciona.
Também é interessante notar que a maioria das pessoas pensa em OOP como sinônimo de "OOP clássico", em que nós criamos taxonomicamente conjuntos e subconjuntos de coisas e, sem ambiguidade, colocamos objetos em um conjunto muito específico. Isso é muito útil para criar novos tipos reutilizáveis, mas não tão bons quando a entidade que você está modelando é praticamente autocontida e, embora inicie interações com outros objetos, raramente, ou nunca, é a alvo de uma interação. Ou pior, quando há poucas (talvez apenas uma) instância desse recurso, ou as instâncias variam muito na composição, no comportamento ou em ambos.
No entanto, há também "OOP prototípico", em que um objeto é descrito escolhendo um semelhante e enumerando os aspectos em que eles diferem. Eu sugeriria este ensaio para um bom e não-demasiado- explicação técnica do processo de pensamento (todo o post é muito grande, mesmo para os padrões de Steve Yegge, então estou apontando para a seção relevante: P). Novamente, isso é uma boa combinação para nossos modelos mentais ao imaginar instâncias desconhecidas em comparação a uma conhecida, mas não necessariamente para como o mundo real "funciona" ... (duas vacas são entidades completamente distintas, mesmo se as percebemos) como sendo "semelhantes" de várias maneiras)
Eu acho que "Does" é a parte importante desta questão. Eu acho que a programação orientada a objetos certamente pode modelar "objetos" do mundo real, mas isso é programação . Não existe nenhuma metodologia que não possa ser abusada, então eu não acho que seja justo dizer "OOP não modela o mundo real" só porque você pode fazer coisas estúpidas com objetos. Não é mais justo do que dizer que o Pointers não é seguro porque você pode fazer coisas estúpidas com ponteiros.
O artigo da Wikipedia sobre o assunto resume bem:
Real-world modeling and relationships
OOP can be used to associate real-world objects and processes with digital counterparts. However, not everyone agrees that OOP facilitates direct real-world mapping (see Negative Criticism section) or that real-world mapping is even a worthy goal; Bertrand Meyer argues in Object-Oriented Software Construction[21] that a program is not a model of the world but a model of some part of the world; "Reality is a cousin twice removed".
O problema é que, a menos que seu programa seja uma simulação de universo, você só se importa com partes do mundo real - daí o "modelo". É para isso que os modelos oferecem a estrutura e a funcionalidade que você precisa exibir.
No mundo real, temos coisas (Objetos) e as coisas podem executar ações (métodos). Podemos quantificar aspectos das coisas (propriedades). OOP tem todo o potencial para modelar as coisas do mundo real quando usado de forma reducionista; cada coisa complexa tem subclasses menores ou mais específicas e todas essas coisas têm interações naturais por meio de métodos.
OOP é um método de abstração, então a coisa prática é se o OOP realmente logicamente modela objetos no mundo real, é menos importante que você não esteja modelando todas as coisas possíveis tudo poderia fazer . Se você precisa fazer todas as coisas possíveis, você não é realmente modelagem .
Para pensar sobre orientação a objetos em seu contexto apropriado, vamos subir um nível de abstração e falar sobre programação em geral, ok?
Independentemente de você usar abordagens OO ou funcionais, seu programa precisa fazer algo, não é? O ponto principal do programa é exibir certos comportamentos dados a um certo conjunto de estímulos. Portanto, os motivos pelos quais os programas existem são porque eles fazem algo. A palavra chave aqui é comportamento .
Além de considerar quais comportamentos um programa deve implementar, seu programa geralmente precisa exibir certas qualidades. Por exemplo, não é suficiente para um programa de monitor cardíaco ter os comportamentos exigidos - geralmente também precisa ser rápido o suficiente para operar em tempo quase real. Outras "qualidades" que um programa pode precisar exibir são: segurança, flexibilidade, modularidade, extensibilidade, legibilidade e assim por diante. Chamamos esses Atributos da qualidade da arquitetura . Assim, podemos dizer que nosso programa precisa atender a certos objetivos comportamentais (funcionais), bem como exibir certas qualidades (não funcionais).
Até agora, nada disso falou sobre OO, tem? Vamos fazer isso agora.
Quando um engenheiro entende os requisitos (comportamentais, AQAs, restrições, etc), surge a pergunta: como devo organizar meu código para que ele faça todas as coisas que ele precisa fazer, além de exibir as qualidades necessárias para ser útil programa? A programação orientada a objetos é uma estratégia para organizar a funcionalidade do seu programa em módulos coesos de objetos cooperativos. A programação funcional é apenas outra estratégia para organizar a funcionalidade do seu programa, e o faz de uma maneira diferente. Ambas as estratégias têm seus pontos strongs e fracos.
Temos assistido a um recente ressurgimento de conceitos funcionais porque ele tem pontos strongs que são muito atraentes para o processamento altamente distribuído, entre outras razões.
Mas voltando ao OO, você pode ver agora que não necessariamente modela o "mundo real"; O que ele faz é organizar o comportamento de seu programa para que seu programa possa exibir as qualidades necessárias para atender a qualquer número de objetivos de negócios. Técnicas como TDD, DDD e BDD são as maneiras pelas quais descobrimos a melhor forma de organizar nossos objetos. Livros como Princípios, padrões e práticas , Software Orientado a Objetos em Crescimento Guiado por Testes , Especificação por Exemplo e Design orientado a domínio apresentam a teoria e a prática da orientação a objetos com foco no design orientado a comportamento .
Quando você lê sobre coisas como "observadores, gerentes, fábricas, etc", você está aplicando padrões OO que ajudam seu programa a exibir certas qualidades que podem ser necessárias para que seja útil. São "receitas comprovadas" que "tendem a funcionar", uma vez que suas necessidades correspondem ao problema que o padrão resolve.
Espero que ajude você a entender o que é OO sem parecer muito preconceituoso entre OO e paradigmas funcionais.
OOP cria um modelo legal do ponto de vista da programação, não reflete o mundo real.
No entanto, existem aproximações muito melhores do mundo real, que são conhecidas pelo termo linguagens específicas de domínio ( DSL ). Por exemplo, o Boo oferece a capacidade de escrever código legível em humanos em inglês simples (exemplo do article ).
apply_discount_of 5.percent:
when order.Total > 1000 and customer.IsPreferred
when order.Total > 10000
suggest_registered_to_preferred:
when order.Total > 100 and not customer.IsPreferred
Outro exemplo seria o uso de estruturas de teste de aceitação de usuário automatizadas com base na linguagem Gherkin .
Feature: Some terse yet descriptive text of what is desired
In order to realize a named business value
As an explicit system actor
I want to gain some beneficial outcome which furthers the goal
Scenario: Some determinable business situation
Given some precondition
And some other precondition
When some action by the actor
And some other action
And yet another action
Then some testable outcome is achieved
And something else we can check happens too
Cabe a você, finalmente. Mas OOP é uma maneira precisa de fazê-lo do que outras metodologias como programação orientada por procedimentos ou estruturada. O tato processual pode resolver seus problemas, mas seguir a POO pode facilitar sua vida.
Tags object-oriented