Membro vs. funções independentes em relação à uniformidade da interface

5

O item 23 de C ++ efetivo (3ª edição) por Scott Meyers é intitulado: "Prefere funções não-membro não-membro para funções-membro". A razão que Scott sugere é o aumento do encapsulamento. Assim, somente as funções que precisam acessar os membros privados são feitas funções-membro, as outras funções são feitas independentes.

Agora, o usuário não se importa com minhas considerações. Tudo o que ele quer é uma interface limpa e uniforme, tão simples de aprender quanto possível. Ter algumas funções como membros e algumas como autônomas parece quebrar essa uniformidade. Além disso, a escolha de qual função é membro e qual é independente pode parecer aleatória para o usuário, que não tem conhecimento dos detalhes da implementação (ou seja, os membros privados) da minha classe.

Uma resposta até cita uma proposta de linguagem relacionada a esse assunto.

Minha pergunta é: é uma boa idéia sempre fornecer uma função de wrapper independente para cada função de membro para apresentar ao usuário uma interface uniforme consistindo apenas de funções independentes?

    
por AlwaysLearning 17.02.2016 / 15:41
fonte

1 resposta

4

Para responder diretamente à pergunta que você fez, eu diria que a resposta curta é não: não é necessariamente útil escrever um wrapper para cada função de membro, apenas para fornecer uma interface uniforme.

Dito isso, pode valer a pena fazê-lo se você tiver algo que corresponda de perto a um conceito, definido inteiramente em termos de funções livres e fornecendo wrappers de função livre, sua classe pode modelar esse conceito. Nesse caso, ter esses wrappers permite usar objetos dessa classe com alguns modelos que não funcionariam com eles. A questão nesse ponto é se esses modelos provavelmente serão úteis para objetos dessa classe em particular. Mesmo que a classe suporte a sintaxe necessária para modelar o conceito, a (s) operação (ões) fornecida (s) por esses modelos pode não ser útil com ela - nesse caso, é obviamente muito sem sentido.

Pelo menos na minha opinião, fornecer invólucros assim x.f(y) pode ser chamado como f(x,y) , apenas para que o programador não precise prestar atenção se f é uma função livre ou uma função de membro é geralmente perdida. Sim, em um mundo completamente ideal, onde o tempo não foi limitado, pode valer a pena considerar. Da mesma forma, em um poucos casos, uma classe pode ser usada tão amplamente e pesadamente que vale a pena considerar investir o tempo extra para escrever o invólucro na esperança de pagar a longo prazo fazendo com que todos os outros vive mais fácil.

Infelizmente, não acho que isso se aplique com muita frequência. A maioria de nós tem uma grande quantidade de problemas pendentes que realmente precisam ser resolvidos para considerá-la seriamente, pelo menos até que tenhamos evidências sólidas e objetivas de que o investimento valerá a pena, e logo em seguida. Fazer isso apenas para cumprir um princípio sem uma garantia bastante sólida de benefícios reais seria difícil de justificar (na melhor das hipóteses).

    
por 17.02.2016 / 17:37
fonte

Tags