Por que OOP é difícil? [fechadas]

92

Quando comecei a usar uma linguagem orientada a objetos (Java), eu simplesmente fui "Legal" e comecei a codificar. Eu realmente nunca pensei nisso até recentemente, depois de ter lido muitas perguntas sobre OOP. A impressão geral que tenho é que as pessoas lutam com isso. Como não achei isso tão difícil, e não diria que sou um gênio, estou pensando que devo ter perdido algo ou entendido mal.

Por que OOP é difícil de entender? É difícil de entender?

gablin
fonte
72
Sou contra: não é difícil de entender, apenas difícil de dominar. A programação como um todo é assim.
Steven Evers
2
hum, não é? Talvez os programadores que não conseguem programar achem difícil culpar os ops em vez de suas linhas de código? Eu não sei, mas nunca ouvi ninguém dizer que é difícil de entender. No entanto, vi pessoas dizer que funcional é estranho, especialmente porque eles não podem alterar o valor de sua variável.
5
@ acidzombie42: funcional não é nada estranho. você não precisa escrever uma lista de comandos para alterar o conteúdo de variáveis ​​que representam um local na RAM. variáveis ​​representam valores, você não altera valores; 42 permanece 42, x permanece x - o que x é. você escreve funções que mapeiam de seus parâmetros para resultados. os valores são: números, listas de valores, funções de valores a valores, programas que produzem efeitos colaterais e um valor resultante na execução e muito mais. Dessa forma, o resultado da função principal será calculado pelo compilador, que é o programa que pode ser executado.
21811 Comonad
5
Eu tenho aprendido Haskell recentemente. Quanto mais eu aprendo e entendo sobre programação funcional, mais sinto que a OOP é difícil. Eu acho que a principal razão para isso é OOP tenta unir os dados (objeto / classe) junto com a função que opera neles (método). Essa é a fonte do problema e muitos padrões de design de POO são criados para evitar a ligação de dados e funções. Por exemplo, o padrão de fábrica é usado para separar o construtor (que é uma função) do objeto real no qual está operando.
precisa saber é o seguinte
1
Porque está com o nome errado. Deveria ser realmente uma programação orientada ao sujeito, na medida em que o sujeito executa a ação (verbo) e o objeto recebe a ação - John jogou a bola. Então johnsBall.throw () realmente não faz sentido.
22612 Chris Cudmore

Respostas:

120

Pessoalmente, achei a mecânica do POO bastante fácil de entender. A parte mais difícil para mim foi o "porquê" disso. Quando fui exposto a ele pela primeira vez, parecia uma solução em busca de um problema. Aqui estão algumas razões pelas quais acho que a maioria das pessoas acha difícil:

  1. IMHO ensinar OO desde o início é uma péssima idéia. A codificação processual não é um "mau hábito" e é a ferramenta certa para alguns trabalhos. Métodos individuais em um programa OO tendem a parecer bastante processuais de qualquer maneira. Além disso, antes de aprender a programação procedural o suficiente para que suas limitações se tornem visíveis, o OO não parece muito útil para o aluno.

  2. Antes de realmente entender o OO, você precisa conhecer o básico de estruturas de dados e funções de ligação tardia / ordem superior. É difícil entender o polimorfismo (que basicamente passa um ponteiro para dados e várias funções que operam nos dados) se você nem entende os conceitos de estruturar dados, em vez de apenas usar primitivos e passar funções de ordem superior / ponteiros para funções.

  3. Os padrões de design devem ser ensinados como algo fundamental para o OO, não como algo mais avançado. Os padrões de design ajudam a ver a floresta através das árvores e fornecem exemplos relativamente concretos de onde o OO pode simplificar problemas reais, e você vai querer aprendê-los eventualmente. Além disso, quando você realmente obtém OO, a maioria dos padrões de design se torna óbvia em retrospectiva.

dsimcha
fonte
5
resposta fabulosa, especialmente o número 1. É claro que os métodos em OO parecem métodos em um idioma processual, mas agora eles estão alojados em objetos que também têm estado.
Dan Rosenstark
3
Gosto especialmente do seu primeiro e terceiro pontos. Meu amigo é louco por padrões de design, e continuo dizendo a ele que, se você apenas usa um bom OOP, a maioria deles deriva muito naturalmente do problema inicial.
CodexArcanum
7
+1 para "A parte mais difícil para mim foi o" porquê "disso". Leva algum tempo e esforço para entender e aplicar os conceitos básicos da linguagem (encapsulamento) e os princípios de design e os métodos de refatoração, em direção a soluções comuns (padrões de design).
Novun
12
Eu concordo com o item 1, com a ressalva de que você precisa fazer um trabalho melhor de explicar OO para pessoas que já sabem programar proceduralmente do que quando eu estava aprendendo. Não, não é útil ou informativo falar sobre uma Catclasse que herda Mammal, use um exemplo real de um programa real que teríamos escrito processualmente. Como uma estrutura de dados simples.
precisa saber é o seguinte
4
Os padrões de design -1 são tão enfatizados hoje em dia. Eles são importantes, com certeza, mas: primeiro, são importantes para todos os paradigmas: funcionais, estruturados e também OO; e segundo, eles não fazem parte do paradigma, apenas um complemento conveniente que você pode usar, como muitos outros. O @SoftwareRockstar explica isso muito bem em sua resposta.
CesarGon
56

Eu acho que existem alguns fatores que ainda não foram mencionados.

Primeiro de tudo, pelo menos em "OOP puro" (por exemplo, Smalltalk), onde tudo é um objeto, você precisa mudar sua mente para uma configuração pouco natural para pensar em um número (por apenas um exemplo) como um objeto inteligente em vez de apenas um valor - já que, na realidade, 21(por exemplo) é realmente apenas um valor. Isso se torna especialmente problemático quando, por um lado, você diz que uma grande vantagem do OOP é modelar a realidade mais de perto, mas você começa adotando o que parece muito com uma visão inspirada em LSD, mesmo das partes mais básicas e óbvias de realidade.

Segundo, a herança no POO também não segue muito de perto os modelos mentais das pessoas. Para a maioria das pessoas, classificar as coisas de maneira mais específica não tem nada perto das regras absolutas necessárias para criar uma hierarquia de classes que funcione. Em particular, criar um class Dque herda de outro class Bsignifica que os objetos class Dcompartilham absolutamente, positivamente todas as características de class B. class Dpode adicionar novas e diferentes características próprias, mas todas as características de class Bdevem permanecer intactas.

Por outro lado, quando as pessoas classificam as coisas mentalmente, elas geralmente seguem um modelo muito mais flexível. Por exemplo, se uma pessoa faz algumas regras sobre o que constitui uma classe de objetos, é bastante típico que quase qualquer regra possa ser quebrada desde que outras regras sejam seguidas. Mesmo as poucas regras que realmente não podem ser violadas quase sempre podem ser "esticadas" um pouco.

Apenas por exemplo, considere "carro" como uma classe. É muito fácil perceber que a grande maioria do que a maioria das pessoas considera "carros" tem quatro rodas. A maioria das pessoas, no entanto, já viu (pelo menos uma foto) um carro com apenas três rodas. Alguns de nós da idade certa também se lembram de um ou dois carros de corrida do início dos anos 80 (mais ou menos) que tinham seis rodas - e assim por diante. Isso nos deixa basicamente com três opções:

  1. Não afirme nada sobre quantas rodas um carro possui - mas isso tende a levar à suposição implícita de que sempre será 4 e código que provavelmente quebrará para outro número.
  2. Afirme que todos os carros têm quatro rodas e apenas os classifique como "não carros", mesmo sabendo que eles realmente são.
  3. Crie a classe para permitir variação no número de rodas, apenas por precaução, mesmo que haja uma boa chance de que esse recurso nunca seja necessário, usado ou testado adequadamente.

Ensinar sobre POO geralmente se concentra na construção de enormes taxonomias - por exemplo, partes do que seria uma hierarquia gigante de toda a vida conhecida na Terra, ou algo nessa ordem. Isso levanta dois problemas: em primeiro lugar, tende a levar muitas pessoas a se concentrarem em grandes quantidades de informações que são absolutamente irrelevantes para a questão em questão. Em um ponto, vi uma discussão bastante longa sobre como modelar raças de cães e se (por exemplo) o "poodle miniatura" deve herdar do "poodle de tamanho completo", ou vice-versa, ou se deve haver uma base abstrata "Poodle "class, com" caniche em tamanho normal "e" caniche em miniatura "ambos herdados dela. O que todos pareciam ignorar era que o aplicativo deveria lidar com o controle de licenças para cães,

Segundo, e quase importante, leva a focar nas características dos itens, em vez de focar nas características importantes para a tarefa em questão. Isso leva a modelar as coisas como estão, onde (na maioria das vezes) o que é realmente necessário é construir o modelo mais simples que atenda às nossas necessidades e usar a abstração para atender às subclasses necessárias para atender à abstração que construímos.

Por fim, direi mais uma vez: estamos lentamente seguindo o mesmo caminho adotado pelos bancos de dados ao longo dos anos. Os primeiros bancos de dados seguiram o modelo hierárquico. Além de se concentrar exclusivamente em dados, essa é uma herança única. Por um curto período de tempo, alguns bancos de dados seguiram o modelo de rede - essencialmente idêntico à herança múltipla (e vistos desse ângulo, várias interfaces não são diferentes o suficiente de várias classes base para perceber ou se preocupar).

Há muito tempo, no entanto, os bancos de dados convergiam amplamente para o modelo relacional (e, embora não sejam SQL, nesse nível de abstração os bancos de dados "NoSQL" atuais também são relacionais). As vantagens do modelo relacional são suficientemente conhecidas que não vou me incomodar em repeti-las aqui. Vou apenas observar que o análogo mais próximo do modelo relacional que temos na programação é a programação genérica (e desculpe, mas, apesar do nome, os genéricos Java, por exemplo, não se qualificam realmente, embora sejam um pequeno passo no direção correta).

Jerry Coffin
fonte
Muito bem afirmado, e especialmente que a maioria dos problemas com OOP que você apresenta não são apenas problemas para os iniciantes entenderem, mas sim questões de OOP em geral que a maioria dos programadores de OOP aprende a pensar. Ultimamente, tenho trabalhado com design de jogos, em que um modelo de componente funciona muito bem, que mapeia de perto a noção de modelos relacionais, e não hierárquicos.
CodexArcanum
7
Heh, eu estava pensando sobre isso outro dia. Como todo o primeiro material de aprendizagem que li no OOP parecia se concentrar na herança, enquanto minha experiência me diz cada vez mais que a herança é geralmente inútil, se não prejudicial.
RMAC
Parece programação orientada a tabelas , embora eu diga que entendi mais que OOP não é a bala de prata do desenvolvimento de software.
OnesimusUnbound
1
@OnesimusUnbound: a diferença é que a programação genérica é uma maneira real e prática de fazer alguma coisa, enquanto a programação orientada a tabela é principalmente um delírio de um lunático sobre uma teoria sobre como algo poderia funcionar (leia as postagens antigas do TopMind em comp.object, e você verei o que quero dizer - na verdade, as postagens podem não ser todas antigas; pelo que sei, ele continua até hoje).
Jerry Coffin
3
É por isso que as interfaces são tão boas. Você pega a modelagem de herança e a inverte para uma abordagem de primeira geração. Por exemplo, no exemplo do cão, pode-se supor que todo cão tenha um gênero e até duas superespécies (uma para cada progenitor) para uma raça específica. Também pode haver uma propriedade de lista contendo características, mas a variedade possível torna inútil colocá-las em uma estrutura definida. É melhor implementar uma pesquisa profunda para rastrear as características e combinar raças semelhantes com base nesses resultados.
Evan Plaice
26

OOP requer a capacidade de pensar abstratamente; um presente / maldição que poucas pessoas, mesmo programadores profissionais, realmente têm.

John Kraft
fonte
35
Toda a programação é abstrata.
Jeffo
28
@ Jeff O - eu discordo. A programação requer apenas a capacidade de dizer a alguém como fazer algo passo a passo. Se você puder dizer a alguém como fazer um sanduíche de manteiga de amendoim e geléia, você poderá digitar comandos em uma interface de programação. Esse é um conjunto de habilidades completamente diferente do que modelar abstratamente o sanduíche de ap, b & j e como ele interage com o mundo.
John John Kraft
16
Entregar a alguém 2 lápis e, em seguida, entregar 1 lápis e perguntar quantos lápis eles têm, é concreto. 2 + 1 = 3 é abstrato.
Jeffo
17
Eu concordo com Jeff. Programar basicamente é gerenciar abstrações. Pelo menos isso é verdade para qualquer coisa, exceto o fluxo de programa mais básico (porque todo o resto será muito complexo sem abstrações). Há uma fase distinta em aprender a programar quando o iniciante aprende a controlar abstrações. É aí que a metáfora da receita cai. Programar não é nada como cozinhar e, embora um algoritmo individual possa ser comparado a uma receita, a programação é fundamentalmente diferente da implementação de algoritmos isolados.
Konrad Rudolph
2
@KonradRudolph Ótimo ponto. +1 em "Todo o resto será muito complexo sem abstrações" .
Karthik Sreenivasan
21

Eu acho que você pode resumir a dificuldade básica desta maneira:

// The way most people think.
Operation - object - parameters
// Example:
Turn the car left.

// The way OOP works conceptually
Object - operation - parameters
// Example:
Car.Turn(270);

Claro, as pessoas podem se acostumar com o mapeamento de "left" como 270, e sim, dizer "Car.Turn" em vez de "turn the car" não é um salto tão grande. MAS, para lidar bem com esses objetos e criá-los, você deve inverter a maneira como pensa normalmente.

Em vez de manipular um objeto, estamos dizendo ao objeto para realmente fazer as coisas por conta própria. Pode não parecer mais difícil, mas dizer a uma janela para se abrir parece estranho. As pessoas que não estão acostumadas a esse modo de pensar precisam lutar repetidamente com essa estranheza até que finalmente se torne natural.

John Fisher
fonte
7
Boa visão. Acho que o problema é que, na vida real, não há muito que um "objeto" possa fazer que não esteja relacionado a outros objetos. OO funciona bem na medida em que os objetos devem modificar seu estado interno: retangle.enlarge (margin_in_pixels), mas eu percebi os limites anos atrás. Um dia, nós programadores estávamos instalando hardware. Alguém estragou "screw.turn" Engraçado, mas isso me fez pensar: com certeza, um parafuso pode mudar sua orientação, mas é realmente uma operação entre o gabinete e o parafuso; nenhum objeto pode executar a tarefa em si. OO simplesmente não é bom o suficiente.
darenw
3
+1, após anos escrevendo "substr (date, 0,4)", é difícil escrever "date.substring (0,4)"
ern0 23/01/11
4
+1 para o snippet de código. Descreve claramente um processo de pensamento real.
Karthik Sreenivasan
2
Na verdade, eu o leio como um comando que você envia. Como em "diga ao carro para virar à esquerda". Opa foi baseado no envio de mensagens para objetos, então é assim que eu interpretaria.
22812 bunglestink
1
Bom comentário, então talvez o OOP seja mais adequado para modelar "sistemas de agentes"?
Qbik
21

Qualquer paradigma exige um certo empurrão "além do limite" para entender, para a maioria das pessoas. Por definição, é um novo modo de pensamento e, portanto, requer uma certa quantidade de abandono de noções antigas e uma certa quantidade de compreensão completa do motivo pelo qual as novas noções são úteis.

Eu acho que grande parte do problema é que os métodos usados ​​para ensinar programação de computadores são muito ruins em geral. OOP é tão comum agora que não é tão perceptível, mas você ainda o vê com frequência na programação funcional:

  • conceitos importantes estão ocultos atrás de nomes ímpares (FP: O que é uma mônada? OOP: Por que eles as chamam de funções e métodos outras vezes?)

  • conceitos estranhos são explicados em metáfora, em vez de em termos do que eles realmente fazem, ou por que você os usaria ou por que alguém pensou em usá-los (FP: Uma mônada é um traje espacial, envolve algum código. objeto é como um pato, pode fazer barulho, andar e herdar de Animal)

  • as coisas boas variam de pessoa para pessoa; portanto, não está claro qual será o ponto de inflexão para qualquer aluno e, muitas vezes, o professor nem se lembra. (FP: Ah, as mônadas permitem que você esconda algo no próprio tipo e continue sem escrever explicitamente o que está acontecendo a cada vez. OOP: Ah, objetos permitem manter as funções de um tipo de dados com esses dados.)

O pior de tudo é que, como a pergunta indica, algumas pessoas imediatamente começam a entender por que o conceito é bom e outras não. Realmente depende de qual é o ponto de inflexão. Para mim, compreender que objetos armazenam dados e métodos para esses dados era a chave, depois disso tudo se encaixava como uma extensão natural. Depois, saltei mais tarde, ao perceber que uma chamada de método de um objeto é muito semelhante a fazer uma chamada estática com esse objeto como o primeiro parâmetro.

Os pequenos saltos mais tarde ajudam a refinar a compreensão, mas é o inicial que tira uma pessoa de "OOP não faz sentido, por que as pessoas fazem isso?" to "OOP é o melhor, por que as pessoas fazem mais alguma coisa?"

CodexArcanum
fonte
8
Eu particularmente odeio o metaforismo, mais frequentemente do que não, eles confundem ao invés de descrever.
Lie Ryan
3
"Mais tarde, pulei ao perceber que uma chamada de método de um objeto é muito semelhante a fazer uma chamada estática com esse objeto como o primeiro parâmetro". Eu gostaria que isso fosse enfatizado mais desde o início, como ocorre em linguagens como Python.
precisa
1
Meu problema com o uso de metáforas para explicar conceitos é que o professor costuma parar na metáfora, como se isso explicasse tudo. Não, isso não é uma explicação completa; isso é apenas uma ilustração para nos ajudar a entender a explicação real .
Jhocking
Ótima resposta! +1 por explicar que o primeiro passo para entender o POO será mais significativo do que o que vem depois como extensões naturais com o bom entendimento da fundação. : D
Karthik Sreenivasan
pontos sobre o aprendizado do "salto": quando comecei a perceber a POO como "meramente" construção modular / estruturada / passo a passo, mas com esteróides; quando reescrevi alguns programas COBOL muito antigos e fora de manutenção. O escopo global da COBOL, apesar de eu ter aplicado essencialmente os princípios de OO, com estruturas de registro personalizadas, variáveis ​​de uso único e parágrafos (métodos), altamente estruturados, modulares e estruturados.
Radarbob #
15

Porque a explicação básica do OOP tem muito, muito pouco a ver com a forma como é usada no campo. A maioria dos programas para ensiná-lo tenta usar um modelo físico, como "Pense em um carro como um objeto, e as rodas como objetos e as portas e a transmissão ...", mas fora de alguns casos obscuros de programação de simulação, os objetos são muito mais frequentemente usados ​​para representar conceitos não físicos ou para introduzir indiretos. O efeito é que isso faz as pessoas entenderem intuitivamente da maneira errada.

Ensinar a partir de padrões de design é uma maneira muito melhor de descrever o POO, pois mostra aos programadores como alguns problemas reais de modelagem podem ser efetivamente atacados com objetos, em vez de descrevê-lo em abstrato.

Dan Monego
fonte
13

Discordo em grande parte da resposta de dsimcha:

  1. Ensinar OO desde o início não é realmente uma má idéia em si, nem ensinar linguagens processuais. O importante é ensinar as pessoas a escrever um código claro, conciso e coeso, independentemente de OO ou processual.

  2. Métodos individuais em bons programas de OO NÃO tendem a ser processuais. Isso está se tornando cada vez mais verdadeiro com a evolução das linguagens OO (leia C # porque, além de C ++, essa é a única outra linguagem OO que eu conheço) e sua sintaxe que fica cada vez mais complexa a cada dia (lambdas, LINQ para objetos etc.). A única semelhança entre métodos e procedimentos OO em linguagens procedurais é a natureza linear de cada uma, que duvido que mudaria tão cedo.

  3. Você também não pode dominar uma linguagem processual sem entender as estruturas de dados. O conceito de ponteiro é tão importante para linguagens procedurais quanto para linguagens OO. A passagem de parâmetros por referência, por exemplo, que é bastante comum em linguagens procedurais, requer que você compreenda os ponteiros o quanto for necessário para aprender qualquer linguagem OO.

  4. Eu não acho que os padrões de design devam ser ensinados no início da programação OO, porque eles não são fundamentais para a programação OO. Definitivamente, pode-se ser um bom programador de OO sem saber nada sobre padrões de design. De fato, uma pessoa pode até estar usando padrões de design conhecidos, mesmo sem saber que eles estão documentados como tal com nomes próprios e que livros são escritos sobre eles. O que deve ser ensinado fundamentalmente são princípios de design, como Responsabilidade Única, Fechamento Aberto e Segregação de Interface. Infelizmente, muitas pessoas que se consideram programadores de OO atualmente não estão familiarizadas com esse conceito fundamental ou apenas optam por ignorá-lo e é por isso que temos tanto código OO de lixo por aí.

Para responder à pergunta do pôster original, sim, OO é um conceito mais difícil de entender do que a programação procedural. Isso ocorre porque não pensamos em termos de propriedades e métodos de objetos da vida real. Por exemplo, o cérebro humano não pensa prontamente em "TurnOn" como um método de TV, mas o vê como uma função do ser humano ligar a TV. Da mesma forma, o polimorfismo é um conceito estranho para o cérebro humano que geralmente vê cada objeto da vida real por apenas uma "face". Herança novamente não é natural para nossos cérebros. Só porque eu sou um desenvolvedor, não significa que meu filho seria um. De um modo geral, o cérebro humano precisa ser treinado para aprender OO, enquanto as linguagens processuais são mais naturais para ele.

SoftwareRockstar
fonte
2
+1 - Eu também não acho que os padrões de design sejam necessários para o ensino de OOP no nível fundamental, você pode ser um bom programador de OOP e não conhecer nenhum padrão de design. Por outro lado, você tende a ver padrões de design conhecidos emergindo naturalmente de bons programadores de POO. Os padrões de design são sempre descobertos, não inventados.
Gary Willoughby
1
+1 - Ótima resposta. Eu gosto do quarto ponto que você afirmou. É bem verdade que se pode ser um bom programador de OO sem saber o que realmente são os padrões de design!
Karthik Sreenivasan
Eu concordo com o nº 4, porque a maioria dos padrões de design nada mais é do que uma abordagem em fita adesiva para codificar expressivamente as limitações da linguagem. Em outros paradigmas, os padrões de design podem ser completamente diferentes e baseados em suas próprias restrições. Não concordo com 2, LINQ e lambdas ainda são executados de maneira processual, eles apenas fornecem abstrações de nível superior ordenadamente empacotadas. Passe algum tempo significativo desenvolvendo com uma linguagem processual / funcional de tipo dinâmico, como JavaScript, e você entenderá o que quero dizer.
Evan Solha
6

Eu acho que muitos programadores têm dificuldade com o design e o planejamento inicial, para começar. Mesmo que alguém faça todo o design para você, ainda é possível romper com os princípios de POO. Se eu pegar um monte de código de espaguete e colocá-lo em uma classe, isso é realmente OOP? Alguém que não entende OOP ainda pode programar em Java. Além disso, não confunda a dificuldade de entender com a falta de vontade de seguir uma determinada metodologia ou discordar dela.

JeffO
fonte
5

Você deve ler Objetos Nunca? Bem, quase nunca. (Associação ACM exigida) por Mordechai Ben-Ari, que sugere que a OOP é tão difícil, porque não é um paradigma que é realmente natural para modelar qualquer coisa. (Embora eu tenha reservas sobre o artigo, porque não está claro quais critérios ele sente que um programa precisa satisfazer para dizer que está escrito no paradigma OOP, em oposição a um paradigma processual usando uma linguagem OO.)

Ken Bloom
fonte
5

A programação orientada a objetos em si não é difícil.

A parte mais difícil é fazê-lo bem. Onde colocar o corte entre o código para que você possa mover facilmente as coisas para o objeto base comum e estendê-las mais tarde? Como tornar seu código utilizável por outras pessoas (estender classes, agrupar proxies, substituir método) sem passar por aros para fazer isso.

Essa é a parte mais difícil e, se bem feita, pode ser muito elegante e se mal feita pode ser muito desajeitada. Minha experiência pessoal é que exige muita prática em todas as situações em que você gostaria que o fizesse de maneira diferente, a fim de fazê-lo bem o suficiente desta vez.

user1249
fonte
"Minha experiência pessoal é que exige muita prática em todas as situações em que você gostaria que o fizesse de maneira diferente, a fim de fazê-lo bem o suficiente desta vez." OOP parece ser uma lista codificada de maneiras de não fazer errado, o que não faz sentido até que você faça tudo errado.
precisa
@ Jared, não exatamente. Compare com a solução de refrigerantes. Existem vários truques que você pode fazer para resolvê-lo, mas leva tempo e prática para fazê-lo bem, sem voltar atrás.
Se alguém pensa em um "objeto de base comum" como um ancestral comum, fica claro. É realmente assim tão simples. É difícil entender porque há tantas explicações enganosas por aí de pessoas tentando parecer inteligentes.
annoying_squid
4

Eu estava apenas assistindo um vídeo de Richard Feynman discutindo como as pessoas podem realmente ter metodologias completamente diferentes na cabeça quando pensam - quero dizer, completamente diferentes.

Quando faço projetos de alto nível, visualizo objetos, posso vê-los, ver suas interfaces e ver quais caminhos as informações precisam percorrer.

Também tenho problemas para lembrar detalhes e achei o OO uma grande ajuda organizacional - muito mais fácil encontrar funcionalidade do que digitalizar uma lista pouco organizada de sub-rotinas.

Para mim, o OO foi um grande benefício, mas se você não visualiza da mesma maneira ou não faz arquitetura de alto nível, provavelmente é inútil e irritante.

Bill K
fonte
+1 Eu me sinto da mesma maneira, mas há muitos empurrões na direção oposta, incluindo Ruby mixins ... o que faz você perceber que OO estrito não é para todos.
Dan Rosenstark
@ Sim, é o que eu estava dizendo. Embora eu pessoalmente não consiga imaginar algo melhor (e Ruby me deixou louca pelo ano em que o usei), estou começando a aceitar que todo mundo tem uma maneira diferente de ver isso. Talvez algumas pessoas usem o toque ou a audição quando pensam em vez de visualizar e o OO simplesmente não se interessa por elas.
Bill K
Eu acho que também ajuda a incentivar convenções de nomenclatura mais naturais. Já não é necessário para codificar o tipo de uma função para a função de nome (tal como INSTR) - porque o nome está ligado ao tipo (como string::find)
Ken Bloom
@Ken embora eu concorde, acho que é mais uma questão de digitação forte do que OO - Ruby tem OO, mas você perde muitas informações de tipo por causa da digitação de pato - Ruby tende a apenas dizer "enviar" e esperar você sabe qual método mágico "ele" deve implementar para funcionar.
Bill K
@ Bill, você está certo. É mais uma questão de linguagens que suportam programação genérica. Você pode obter boas convenções de nomenclatura natural com sistemas de módulos e tipeclass como o de Haskell, e não há nada OO sobre Haskell. Se C havia sobrecarga, você poderá obter os mesmos tipos de nomes genéricos em C.
Ken Bloom
4

Eu já tinha feito bastante a programação GW-Basic e Turbo Pascal antes de ser apresentado ao OO, então, inicialmente, ele fez minha cabeça.

Não faço ideia se é isso que acontece com os outros, mas para mim foi assim: meu processo de pensamento sobre programação era puramente processual. Como em: "tal e tal acontece, então tal e tal acontece a seguir", etc. Eu nunca considerei as variáveis ​​e os dados nada mais que atores fugazes no fluxo do programa. A programação era "o fluxo de ações".

Suponho que o que não foi fácil de entender (por mais estúpido que pareça para mim agora), foi a idéia de que os dados / variáveis ​​realmente importam , em um sentido mais profundo do que apenas ser atores fugazes no "fluxo" do programa. Ou, em outras palavras: continuei tentando compreendê-lo pelo que acontece , e não pelo que é , que é a verdadeira chave para entender isso.

Bobby Tables
fonte
Ponto de vista interessante. Enquanto luto para entender um projeto maciço de C ++, acho que sou o oposto, pensando principalmente em termos de dados, o "caminho do sinal" dos bits, de alguma "entrada" a outra "saída". Enquanto eu também fazia muito Basic e Pascal, meu primeiro pensamento técnico foi em eletrônica.
darenw
3

Não acho difícil entender, mas pode ser que muitos dos programadores consultados sejam novos no conceito, vindos de linguagens procedurais.

Pelo que tenho visto / lido muitas pessoas (pelo menos nos fóruns) procuram um 'resultado' do OOP. Se você é um programador de procedimentos que não volta e modifica estender seu código, provavelmente pode ser difícil entender os benefícios.

Além disso, há muita POO ruim por aí, se as pessoas estão lendo / vendo isso, é fácil ver por que elas podem achar isso difícil.

OMI, você precisa esperar até ouvir um clique ou ser ensinado por alguém com conhecimento real, não acho que você possa se apressar.

DBlackborough
fonte
5
Se você vem de um ambiente acadêmico, os tipos de programas de brinquedos que você escreve ali também parecem inúteis no OOP. Comecei a aprender C na faculdade, e isso era fácil de entender porque cada programa era de uma página, com menos de 100 linhas. Então você tenta aprender OOP e exige toda essa bagagem e sobrecarga de objetos apenas para fazer a mesma coisa, e isso parece inútil. Mas até você escrever um programa em vários arquivos e milhares de linhas, é difícil perceber por que qualquer estilo de programação é útil.
CodexArcanum
3

Eu acho que a razão pela qual o POO é difícil para muitos é porque as ferramentas realmente não o facilitam.

Hoje, as linguagens de computador são uma abstração do que está acontecendo no computador.

OOP é uma maneira abstraída de representar abstrações.

Então, estamos usando uma abstração para criar abstrações com uma abstração. Acrescente a isso que o que estamos abstraindo são geralmente interações físicas / sociais muito complexas e, bem, não é de admirar.

ElGringoGrande
fonte
2

Na verdade, eu tenho um blog chamado "Lutas na programação orientada a objetos", que nasceu de algumas das minhas lutas com o aprendizado. Eu acho que foi particularmente difícil para mim entender porque eu gastei muito tempo usando programação procedural, e tive dificuldade em entender a idéia de que um objeto poderia ser representado por uma coleção de atributos e comportamentos (eu estava acostumado a simplesmente uma coleção de variáveis ​​e métodos).

Além disso, existem muitos conceitos que orientam um objeto de linguagem - herança, interfaces, polimorfismo, composição, etc. Há muito o que aprender sobre a teoria dele antes que você possa realmente escrever código de maneira eficaz e de uma maneira orientada a objetos. maneira, enquanto na programação procedural, é simplesmente uma questão de entender coisas como alocação de memória para variáveis ​​e chamadas de ponto de entrada para outros métodos.

Tim Claason
fonte
Concordo - muitas das dificuldades que as pessoas têm com o OO são que elas se treinaram para pensar 'proceduralmente'. Não há nada inerentemente difícil no OO, mas se você 'conhecer' as técnicas processuais, seria uma surpresa ver outra maneira de estruturar as coisas.
Kirk Broadhurst
Sem dúvida, é uma maneira completamente diferente de pensar da programação procedural. Mas, ao contrário do que muitos dizem, não é A) um modo de pensar não natural e B) complicado. Eu apenas acho que não é ensinado bem.
annoying_squid
2

Motivação. É mais difícil aprender alguma coisa quando você não vê o porquê e também quando não consegue ver o que fez e descobrir se fez certo ou não.

O que é necessário são pequenos projetos que usam OO para fazer coisas úteis. Sugiro que você leia um livro sobre padrões de design e crie um que é obviamente útil e funciona bem com o OO. (Usei o Strategy da vez em que tentei. Algo como Flyweight ou Singleton seria uma má escolha, pois são maneiras de usar objetos em geral, não de objetos para realizar alguma coisa.)

David Thornley
fonte
As pessoas sempre falam sobre Singleton, mas ele sempre é convidado para a festa. Mas é verdade, ele não é o OO OO DP.
Dan Rosenstark
-1

Eu acho que depende da idade (idade como proxy da experiência) e, mais importante, do interesse. Se você é "jovem" (ou seja, verde, talvez) e nunca pensou em outra maneira, parece bastante direto. Por outro lado, se você acha que é a coisa mais legal que você já viu - aconteceu comigo aos 28 anos ou algo assim - é fácil gritar.

Por outro lado, se você pensa, como muitos de meus alunos de Java, "por que estamos aprendendo isso, é apenas uma moda passageira", é praticamente impossível aprender. Isso é verdade com a maioria das tecnologias.

Yar
fonte
1
OO uma moda? Quantos anos tem seus alunos - eu suspeito que esse "modismo" seja mais antigo do que eles (o primeiro OO que fiz - que eu sabia que fiz - era Simula em 1983/4 e Simula não era novo naquele momento)
Murph
@ Murph Isso aconteceu entre 2004 e 2005 e os estudantes definitivamente tinham mais de 45 a 50 anos (programadores profissionais na Iberia).
Dan Rosenstark
ok, eu meio que posso ver como eles podem ter perdido o começo da coisa OO. Mas em 2004/5 estávamos no .NET, que é praticamente OO de parede a parede (-: há coisas em desenvolvimento que podemos descrever como modismos, mas aquelas que não fracassam rapidamente tendem a evoluir para coisas boas
Murph
1
@ Murph, para ser sincero, esses caras eram programadores de mainframe que estavam tentando converter para Java. Foi realmente uma experiência divertida e única (tarifa não normal para os meus dias no Java Trainer). Ele é verdade, porém, que tinham visto muitas coisas vêm e vão, mas, obviamente, OO é mais do que uma moda passageira. Em uma nota separada: eu meio que esperava que esse teste de unidade se tornasse uma moda passageira, mas agora acho que tenho muitos testes de unidade para escrever ... :) #
9601 Dan Rosenstark
-1

Independentemente de qual paradigma (OOP, funcional etc.) você escolher, para escrever um programa de computador, você precisa saber quais etapas o seu programa fará.

A maneira natural de definir um processo é anotar suas etapas, para tarefas maiores, você as divide em etapas menores. Esta é a maneira processual, é assim que o computador funciona, é assim que você percorre sua lista de verificação passo a passo.

OOP é uma maneira diferente de pensar. Em vez de pensar em uma lista de tarefas que precisam ser realizadas passo a passo, você pensa nos objetos, suas habilidades e relacionamentos. Então você escreverá muitos objetos, métodos pequenos e seu programa funcionará magicamente. Para conseguir isso, você precisa torcer sua mente ...

E é por isso que OOP é difícil. Como tudo é um objeto, tudo o que eles fazem é pedir a outros objetos que façam alguma coisa, e esses outros objetos basicamente fazem alguns. Portanto, o controle em um programa OOP pode ir muito além entre os objetos.

Calmarius
fonte
-1

Como alguém que atualmente está aprendendo programação e tendo alguns problemas nessa área, não acho que seja tão difícil entender o conceito quanto as implementações específicas desse conceito. Digo isso porque tenho a idéia do OOP e o uso no PHP há cerca de um ano, mas conforme passo para o C # e observo o uso de objetos por outros programadores, percebo que muitas pessoas o fazem da mesma maneira. que eu simplesmente não entendo. É isso especificamente que me levou a encontrar uma melhor compreensão dos princípios da OOP.

Obviamente, percebo que o problema é provavelmente a minha falta de experiência com uma linguagem nativamente OOP, e que, com o passar do tempo, encontrarei novas maneiras de utilizar objetos que não são tão claros para um novo programador quanto o que sou. atualmente experimentando. Jerry Coffin aborda isso algumas vezes, particularmente em seu comentário:

Isso se torna especialmente problemático quando, por um lado, você diz que uma grande vantagem do OOP é modelar a realidade mais de perto, mas você começa adotando o que parece muito com uma visão inspirada em LSD, mesmo das partes mais básicas e óbvias de realidade.

Acho que isso é muito preciso, pois é a impressão que muitas vezes tenho quando vejo alguém criando classes para coisas que não são realmente coisas - um exemplo específico me escapa, mas o mais próximo que posso chegar em tempo real é tratar a distância como um objeto (vou editar na próxima vez que vir algo que causa essa mesma confusão). Às vezes, o OOP parece desconsiderar temporariamente suas próprias regras e se torna menos intuitivo. Isso ocorre com mais frequência quando objetos estão produzindo objetos, herdados de uma classe que os está encapsulando, etc.

Penso que para alguém como eu, ajuda pensar no conceito de objetos como tendo múltiplas facetas, uma das quais inclui tratar algo como um objeto quando, de outra forma, não seria. Algo como a distância, com apenas uma pequena mudança de paradigma, poderia parecer um objeto teórico, mas não um que pudesse ser segurado em sua mão. Eu tenho que pensar nisso como tendo um conjunto de propriedades, mas um conjunto mais abstrato de comportamentos, como acessar suas propriedades. Não tenho certeza de que essa seja a chave do meu entendimento, mas parece ser para onde meus estudos atuais estão levando.

dsimer
fonte
1
Um par de pontos ou objetos deve ser considerado como um objeto. E a distância deve ser tomada como uma função do objeto. Usar objetos não significa que você cria objetos de tudo.
Gangnus
Como eu disse, a distância foi um exemplo ruim. Quanto a criar um objeto de tudo, refiro-me especificamente ao que vi acontecer, não ao que realmente fiz - o que ainda não é nada.
dsimer
Depende do idioma - no SmallTalk a distância (e tudo) É um objeto. Mas em C # você mencionou que seria ruim.
Gangnus
-2

As terminologias foram o meu obstáculo ao aprender os princípios da programação orientada a objetos (POOP). É quando você compreende os fundamentos que as peças começam a se encaixar. Assim como todas as coisas que aprendem novos conceitos são um pouco difíceis.

Concordou que os padrões de design devem ser trabalhados pelo menos paralelamente ao OOP.

lord-fu
fonte
-2

O salto principal para mim foi apenas entender o conceito abstrato de OOP. Agora, sou muito novo em programação em geral. Estou programando há um ano a um ano e meio, então minha introdução ao OOP foi com Actionscript and Processing. Quando aprendi a codificação Actionscript, ela não estava no OOP. Aprendi a codificar diretamente no painel Actions e foi assim que aprendi os fundamentos básicos da programação (variáveis, funções, loops etc.). Aprendi como fazer algo diretamente no palco do Flash ou Processing.

Quando a OOP surgiu, perceber que eu poderia criar métodos e propriedades dentro de um objeto para poder usar e reutilizar foi um pouco difícil de entender no começo. Tudo era muito abstrato e difícil de processar, mas as linguagens de programação eram muito melhores, mas foi preciso um pouco de fé para estabelecer essas conexões no início.

Kobby
fonte
Uau, uma parte disso não fazia nenhum sentido. "Tudo era muito abstrato e difícil de processar entre classes e instâncias de objetos etc. Mas as linguagens de programação tornaram-se muito mais fáceis de entender quando eu obtive OOP. Mas foi preciso um pouco de esforço para fazer essas conexões no início"
-2

Receita

Boa compreensão de POO = bom mentor ou bons livros ou ambos + interesse pessoal + prática.

Interesse pessoal

Da minha experiência pessoal, o interesse pessoal percorre um longo caminho para atravessar a ponte da programação processual para a OOP, com as informações corretas de mentores, bons livros ou ambos combinados .

Prática, Prática e Prática

Meu melhor amigo para entender melhor o POO não passou de prática. Isso definitivamente promoverá suas habilidades de OOP.

Como diz o ditado: "Não há substituto para o trabalho duro nem atalho para o sucesso".

Boa sorte!

Karthik Sreenivasan
fonte