Eu não entendo os argumentos contra sobrecarga de operador [fechado]

Acabei de ler um dos artigos de Joel em que ele diz:

Em geral, tenho que admitir que tenho um pouco de medo de recursos de linguagem que ocultam as coisas . Quando você vê o código

i = j * 5;

... em C, você sabe, pelo menos, que j está sendo multiplicado por cinco e os resultados armazenados em i.

Mas se você vir esse mesmo trecho de código em C ++, não saberá nada. Nada. A única maneira de saber o que realmente está acontecendo no C ++ é descobrir quais são os tipos iej, algo que pode ser declarado em outro lugar. Isso porque j pode ser de um tipo que tenha operator*sobrecarregado e faz algo terrivelmente espirituoso quando você tenta multiplicá-lo.

(Ênfase minha.) Com medo de recursos de linguagem que ocultam as coisas? Como você pode ter medo disso? Ocultar coisas (também conhecidas como abstração ) não é uma das idéias principais da programação orientada a objetos? Sempre que você chama um método a.foo(b), você não tem idéia do que isso pode fazer. Você precisa descobrir quais tipos ae quais bsão, algo que pode ser declarado em algum outro lugar. Então, devemos acabar com a programação orientada a objetos, porque esconde muitas coisas do programador?

E como é j * 5diferente de j.multiply(5)qual você pode escrever em um idioma que não suporta sobrecarga de operador? Novamente, você teria que descobrir o tipo je espiar dentro do multiplymétodo, porque eis que ele jpode ser de um tipo que possui um multiplymétodo que faz algo terrivelmente espirituoso.

"Muahaha, sou um programador malvado que nomeia um método multiply, mas o que ele realmente faz é totalmente obscuro e não intuitivo e não tem absolutamente nada a ver com a multiplicação das coisas". Esse é um cenário que devemos levar em consideração ao projetar uma linguagem de programação? Então, temos que abandonar identificadores de linguagens de programação com o argumento de que eles podem ser enganosos!

Se você quiser saber o que um método faz, pode dar uma olhada na documentação ou espiar dentro da implementação. Sobrecarga de operador é apenas açúcar sintático, e não vejo como isso muda o jogo.

Por favor me esclareça.

A abstração 'oculta' o código para que você não precise se preocupar com o funcionamento interno e, muitas vezes, para não poder alterá-lo, mas a intenção não era impedir que você o visse. Apenas fazemos suposições sobre os operadores e, como Joel disse, pode estar em qualquer lugar. Ter um recurso de programação que exija que todos os operadores sobrecarregados sejam estabelecidos em um local específico pode ajudar a encontrá-lo, mas não tenho certeza se isso facilita o uso.

Não vejo fazer * fazer algo que não se pareça com a multiplicação melhor do que uma função chamada Get_Some_Data que exclui dados.

IMHO, recursos de linguagem como sobrecarga do operador dão ao programador mais poder. E, como todos sabemos, com grande poder vem uma grande responsabilidade. Os recursos que lhe dão mais poder também oferecem mais maneiras de dar um tiro no próprio pé e, obviamente, devem ser usados ​​criteriosamente.

Por exemplo, faz todo o sentido sobrecarregar +o *operador ou o operador class Matrixor class Complex. Todos saberão instantaneamente o que isso significa. Por outro lado, para mim, o fato de +significar concatenação de strings não é de todo óbvio, mesmo que Java faça isso como parte da linguagem e STL faça por std::stringusar sobrecarga de operador.

Outro bom exemplo de quando a sobrecarga do operador torna o código mais claro são os ponteiros inteligentes em C ++. Você deseja que os ponteiros inteligentes se comportem como ponteiros regulares o máximo possível, por isso faz todo o sentido sobrecarregar os unários *e os ->operadores.

Em essência, a sobrecarga do operador nada mais é do que outra maneira de nomear uma função. E existe uma regra para nomear funções: o nome deve ser descritivo, tornando imediatamente óbvio o que a função faz. A mesma regra exata se aplica à sobrecarga do operador.

No Haskell "+", "-", "*", "/" etc são apenas funções (infix).

Você deve nomear uma função infix "mais" como em "4 mais 2"? Por que não, se adição é o que sua função faz. Você deve nomear sua função "mais" como "+"? Por que não.

Penso que o problema com os chamados "operadores" é que eles se assemelham principalmente a operações matemáticas e não existem muitas maneiras de interpretá-las e, portanto, há grandes expectativas sobre o que esse método / função / operador faz.

EDIT: deixou meu argumento mais claro

Com base nas outras respostas que já vi, só posso concluir que a verdadeira objeção à sobrecarga do operador é o desejo de código imediatamente óbvio.

Isso é trágico por dois motivos:

1. Levado a sua conclusão lógica, o princípio de que o código deveria ser imediatamente óbvio teria todos nós ainda codificando em COBOL.
2. Você não aprende com o código que é imediatamente óbvio. Você aprende com o código que faz sentido depois de dedicar algum tempo para pensar em como ele funciona.

Eu concordo um pouco.

Se você escrever multiply(j,5), jpode ser do tipo escalar ou matriz, tornando-se multiply()mais ou menos complexo, dependendo do que jé. No entanto, se você abandonar completamente a idéia de sobrecarregar, a função terá que ser nomeada multiply_scalar()ou o multiply_matrix()que tornaria óbvio o que está acontecendo por baixo.

Há código em que muitos de nós preferiríamos de uma maneira e há código em que a maioria de nós preferia de outra maneira. A maior parte do código, no entanto, cai no meio termo entre esses dois extremos. O que você prefere depende do seu histórico e preferências pessoais.

Eu vejo dois problemas com sobrecarga do operador.

1. A sobrecarga altera a semântica do operador, mesmo que isso não seja pretendido pelo programador. Por exemplo, quando você sobrecarregar &&, ||ou ,, você perde os pontos de seqüência que estão implícitas pelas variantes embutidos destes operadores (bem como o comportamento de curto-circuito dos operadores lógicos). Por esse motivo, é melhor não sobrecarregar esses operadores, mesmo que o idioma permita.
2. Algumas pessoas veem a sobrecarga do operador como um recurso tão bom que começam a usá-lo em qualquer lugar, mesmo que não seja a solução apropriada. Isso faz com que outras pessoas reajam demais na outra direção e alertam contra o uso de sobrecarga do operador. Não concordo com nenhum dos grupos, mas tome o meio termo: a sobrecarga do operador deve ser usada com moderação e somente quando
   • o operador sobrecarregado tem o significado natural para os especialistas em domínio e os especialistas em software. Se esses dois grupos não concordarem com o significado natural para o operador, não o sobrecarregue.
   • para o (s) tipo (s) envolvido (s), não há significado natural para o operador e o contexto imediato (de preferência a mesma expressão, mas não mais do que algumas linhas) sempre deixa claro qual é o significado do operador. Um exemplo dessa categoria seria operator<<para fluxos.

Com base na minha experiência pessoal, a maneira Java de permitir vários métodos, mas não sobrecarregar o operador, significa que sempre que você vê um operador, sabe exatamente o que ele faz.

Você não precisa ver se *chama um código estranho, mas sabe que é uma multiplicação e se comporta exatamente como na maneira definida pela Especificação de Linguagem Java. Isso significa que você pode se concentrar no comportamento real em vez de descobrir todas as coisas definidas pelo programador.

Em outras palavras, proibir a sobrecarga do operador é um benefício para o leitor , não para o gravador e, portanto, facilita a manutenção dos programas!

Uma diferença entre sobrecarga a * be chamada multiply(a,b)é que a última pode ser facilmente recebida. Se a multiplyfunção não estiver sobrecarregada para tipos diferentes, você poderá descobrir exatamente o que a função fará, sem precisar rastrear os tipos de ae b.

Linus Torvalds tem um argumento interessante sobre a sobrecarga do operador. Em algo como o desenvolvimento do kernel Linux, onde a maioria das alterações é enviada por meio de correções por email, é importante que os mantenedores possam entender o que um patch fará com apenas algumas linhas de contexto em torno de cada alteração. Se funções e operadores não estiverem sobrecarregados, o patch poderá ser lido com mais facilidade de maneira independente do contexto, pois você não precisará examinar o arquivo alterado para descobrir quais são todos os tipos e verificar se há operadores sobrecarregados.

Suspeito que tenha algo a ver com quebrar expectativas. Já estou acostumado a C ++, o comportamento do operador não é totalmente determinado pela linguagem e você não ficará surpreso quando um operador fizer algo estranho. Se você está acostumado a idiomas que não possuem esse recurso e vê o código C ++, traz consigo as expectativas desses outros idiomas e pode se surpreender ao descobrir que um operador sobrecarregado faz algo estranho.

Pessoalmente, acho que há uma diferença. Quando você pode alterar o comportamento da sintaxe interna do idioma, torna-se mais opaco para se pensar. Os idiomas que não permitem a metaprogramação são sintaticamente menos poderosos, mas conceitualmente mais simples de entender.

Eu acho que sobrecarregar operadores matemáticos não é o problema real da sobrecarga de operadores em C ++. Eu acho que sobrecarregar operadores que não devem confiar no contexto da expressão (ou seja, tipo) é "mau". Por exemplo, sobrecarga , [ ] ( ) -> ->* new deleteou mesmo o unário *. Você tem um certo conjunto de expectativas daqueles operadores que nunca devem mudar.

Entendo perfeitamente que você não gosta do argumento de Joel sobre se esconder. Nem eu. É realmente muito melhor usar '+' para coisas como tipos numéricos incorporados ou para os seus próprios, como, por exemplo, matriz. Admito que isso é puro e elegante para poder multiplicar duas matrizes com o '*' em vez de '.multiply ()'. E, afinal, temos o mesmo tipo de abstração nos dois casos.

O que dói aqui é a legibilidade do seu código. Na vida real, não no exemplo acadêmico de multiplicação de matrizes. Especialmente se a sua linguagem permitir definir operadores que não estão presentes inicialmente no núcleo da linguagem, por exemplo =:=. Muitas perguntas extras surgem neste momento. O que é esse maldito operador? Quero dizer, qual é a precedência dessa coisa? Qual é a associatividade? Em que ordem é a =:= b =:= crealmente executada?

Esse já é um argumento contra a sobrecarga do operador. Ainda não está convencido? Verificar as regras de precedência levou mais de 10 segundos? Ok, vamos mais longe.

Se você começar a usar uma linguagem que permita a sobrecarga do operador, por exemplo, a popular cujo nome começa com 'S', você aprenderá rapidamente que os designers de bibliotecas gostam de substituir os operadores. É claro que eles são bem-educados, seguem as melhores práticas (sem cinismo aqui) e todas as suas APIs fazem todo sentido quando as olhamos separadamente.

Agora imagine que você precisa usar algumas APIs que fazem uso pesado de operadores que sobrecarregam juntos em um único pedaço de código. Ou melhor ainda - você precisa ler um código legado como esse. É quando a sobrecarga do operador é realmente péssima. Basicamente, se houver muitos operadores sobrecarregados em um local, eles logo começarão a se misturar com os outros caracteres não alfanuméricos no código do programa. Eles se misturam com caracteres não alfanuméricos que não são realmente operadores, mas com alguns elementos gramaticais de linguagem mais fundamentais que definem coisas como blocos e escopos, modelam instruções de controle de fluxo ou denotam algumas meta-coisas. Você precisará colocar os óculos e aproximar os olhos 10 cm da tela LCD para entender essa bagunça visual.

Em geral, evito usar a sobrecarga do operador de maneiras não intuitivas. Ou seja, se eu tiver uma classe numérica, a sobrecarga * é aceitável (e incentivada). No entanto, se eu tiver uma classe Employee, o que sobrecarregar * faria? Em outras palavras, sobrecarregue os operadores de maneiras intuitivas que facilitam a leitura e a compreensão.

Aceitável / Incentivado:

class Complex
{
public:
    double r;
    double i;

    Complex operator*(const Compex& rhs)
    {
        Complex result;
        result.r = (r * rhs.r) - (i * rhs.i);
        result.i = (r * rhs.i) + (i * rhs.r);
        return result;
    }
};

Não aceitável:

class Employee
{
public:
    std::string name;
    std::string address;
    std::string phone_number;

    Employee operator* (const Employee& e)
    {
        // what the hell do I do here??
    }
};

Além do que já foi dito aqui, há mais um argumento contra a sobrecarga do operador. De fato, se você escreve +, isso é óbvio que você quer dizer adição de algo a algo. Mas nem sempre é esse o caso.

O próprio C ++ fornece um ótimo exemplo desse caso. Como stream << 1deve ser lido? fluxo mudou para a esquerda por 1? Não é óbvio, a menos que você saiba explicitamente que << em C ++ também grava no fluxo. No entanto, se essa operação fosse implementada como um método, nenhum desenvolvedor sadio escreveria o.leftShift(1), seria algo parecido o.write(1).

A conclusão é que, ao tornar a sobrecarga do operador indisponível, a linguagem faz com que os programadores pensem nos nomes das operações. Mesmo que o nome escolhido não seja perfeito, ainda é mais difícil interpretar um nome do que um sinal.

Em comparação aos métodos detalhados, os operadores são mais curtos, mas também não exigem parênteses. Parênteses são relativamente inconvenientes para digitar. E você deve equilibrá-los. No total, qualquer chamada de método requer três caracteres de ruído simples em comparação com um operador. Isso torna o uso de operadores muito, muito tentador.
Por que mais alguém iria querer isso cout << "Hello world":?

O problema com a sobrecarga é que a maioria dos programadores é incrivelmente preguiçosa e a maioria dos programadores não pode se dar ao luxo de ser.

O que leva os programadores de C ++ a abusar da sobrecarga do operador não é a sua presença, mas a ausência de uma maneira mais clara de executar chamadas de método. E as pessoas não têm apenas medo de sobrecarregar o operador porque isso é possível, mas porque está feito.
Observe que, por exemplo, em Ruby e Scala, ninguém tem medo de sobrecarregar o operador. Além do fato de que o uso de operadores não é realmente mais curto que os métodos, outro motivo é que Ruby limita a sobrecarga de operadores a um mínimo sensato, enquanto o Scala permite que você declare seus próprios operadores , evitando assim a trivialidade de colisões.

A razão pela qual a Sobrecarga do operador é assustadora, é porque há um grande número de programadores que nunca pensariam que *não significa simplesmente "multiplicar", enquanto um método como foo.multiply(bar)pelo menos instantaneamente indica ao programador que alguém escreveu um método de multiplicação personalizado . Nesse momento, eles se perguntariam o porquê e iriam investigar.

Eu trabalhei com "bons programadores" que estavam em posições de alto nível que criariam métodos chamados "CompareValues" que levariam 2 argumentos e aplicariam os valores de um ao outro e retornariam um booleano. Ou um método chamado "LoadTheValues" que iria ao banco de dados para outros 3 objetos, obter valores, fazer cálculos, modificar thise salvá-lo no banco de dados.

Se estou trabalhando em uma equipe com esses tipos de programadores, sei instantaneamente investigar as coisas em que eles trabalharam. Se eles sobrecarregaram um operador, não tenho como saber que eles fizeram isso, exceto supor que eles fizeram e continuar procurando.

Em um mundo perfeito, ou em uma equipe com programadores perfeitos, a sobrecarga do operador é provavelmente uma ferramenta fantástica. Ainda tenho que trabalhar em uma equipe de programadores perfeitos, por isso é assustador.