Executando verificação de segurança...
Em resposta a [Não disponível]
2
kht

Vale lembrar que não existe uma definição única, canônica e universal sobre Orientação a Objetos. A definição dada acima é uma das existentes, mas na realidade o buraco é mais embaixo.

Sugiro ler os 2 links indicados no parágrafo anterior, só para começar. Depois, pode ler esse (uma análise bem detalhada sobre as "escolas de orientação a objeto existentes"), e por fim leia o que Alan Kay (o sujeito da esquerda na imagem abaixo, considerado o criador do termo "Orientação a Objeto") disse sobre isso: aqui e aqui.

O que é OO? Nem os maiores especialistas concordam

E tem também este artigo que faz uma comparação mais detalhada sobre as duas "escolas" da imagem acima.

De qualquer forma, usar classes não é a única forma de "fazer código OO". Claro que hoje em dia é a mais usada por muitas linguagens que se dizem orientadas a objetos, mas existem outras. JavaScript, por exemplo: como já citado, ela usa protótipos (no caso do JS, a palavra-chave class é meio que um syntatic sugar, pois por baixo dos panos continuam sendo protótipos e funções construtoras).

E claro, é possível ter todas as características citadas (polimorfismo, modularidade, encapsulamento, etc) sem classes (até em C, por exemplo, dá pra ter tudo isso). O mecanismo de classes pode facilitar, é verdade, mas não quer dizer que é o único jeito.

2
maniero

Principalmente a ideia de "mundo real" é bem controversa, na verdade já bastante refutada, já constando só nos anais marketeiros e reproduções desavisadas. Não é possível reproduzir o mundo real e qualquer tentativa só cria problemas para o código. Tem que afastar essa ideia de imediato. Acho que falaram assim pra facilitar o entendimento, mas as pessoas levaram ao pé da letra e começaram fazer isso.

Obrigado por citar algo que eu postei.

Eu postagens mais recentes eu cito que até o Alan Kay admite, bem mais ou menos, não quer dar o braço a torcer, que ele inventou a orientação a mensagens e não a orientação a objetos, só que deu esse título, inventado por ele sim, para a outra invenção :)

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).

2
kht
Autor
Autor

Essa questão de "modelar o mundo real" é algo que deveria sumir das apostilas. É uma metáfora tão falha que acaba induzindo ao erro e causando mais mal do que bem. Sobre isso, gosto muito de um trecho desta resposta:

"Aves voam. Avestruzes são aves, só que não voam. Aviões também voam, mas não batem as asas. Foguetes voam, e nem têm asas! Patos são aves, e também nadam. Barcos não nadam, mas é quase isso... Aviões, foguetes e barcos são veículos. Mísseis parecem foguetes, mas não transportam passageiros."

O contexto ali é sobre usar herança ou composição, e os desafios de se criar um modelo adequado e fiel à realidade. A citação acima mostra que não importa a modelagem que fizermos, nunca será 100% fiel ao "mundo real". Toda abstração tem limites.

No fim das contas, não devemos modelar o mundo real, e sim alguns aspectos do mundo real que são relevantes para o problema que queremos resolver.

Eu até entendo que a metáfora pode ajudar nas etapas iniciais do aprendizado, mas é algo que deveria ser esclarecido logo em seguida (e raramente é feito, basta ver a quantidade de "seniors" que ainda acreditam nisso).

2
maniero

Eu sempre falo que a maioria das pessoas não sabem programar OO porque os exemplos dos materiais didáticos são para fazer entender o conceito e o mecanismo, mas não para treinar o uso. Só que eles não deixam isso muito claro, e não induzem fazer o certo. Consequência: as pessoas treinam o erro, e é ele que ela passa fazer sempre. E muitas vezes ensinam outras pessoas assim.

Modelar é muito difícil. Em muitos casos é melhor procurar algo mais simples que não se preocupe tanto com o modelo, porque modelar errado pode causar mais estrago. Os menos inexperientes não percebem isso. Eu percebo, e ainda cometo erros.