Funzione indipendente che chiama una funzione membro che cambia lo stato: una cattiva pratica?

Question

Funzione indipendente che chiama una funzione membro che cambia lo stato: una cattiva pratica?

#1 da (6 voti)
#2 da (1 voti)

4

L'articolo 23 di Effective C ++ (3a edizione) di Scott Meyers è intitolato: "Preferisci le funzioni non amichevoli non membro alle funzioni membro". Ho capito che l'intenzione di Scott era che, ogni volta che una funzione può essere implementata in termini del set minimo esistente di funzioni membro, dovrebbe essere resa indipendente.

Tuttavia, oggi ho visto un'opinione che avere una funzione indipendente che chiama una funzione membro che cambia lo stato è una cattiva pratica. Questa opinione afferma fondamentalmente che tutte le funzioni indipendenti devono essere pure. È una comprensione universale o anche la mia comprensione iniziale è giustificabile?

c++

posta AlwaysLearning 17.02.2016 - 18:27

fonte

2 risposte

Leggi altre domande sui tag c++

API REST - proprietà omesse nella richiesta POST: come devono essere gestite? Meglio avere due variabili per designare se esiste una variabile, o una

score 6 · Answer 1

È lontano da una comprensione universale. In effetti, una buona parte della libreria di template standard C ++ (come < algorithm > per un esempio di rilievo) segue Scott Il consiglio di Meyers mentre si modifica il contenitore sottostante.

Immagino che l'argomento principale dell'opinione che hai visto è che la funzione indipendente "nasconde" il cambiamento di stato della funzione membro sottostante, ma questo è un argomento contro la mutabilità in generale e non avrebbe importanza quale tipo di chiamata la funzione si trova nel livello sopra la chiamata al metodo di modifica dello stato. Non fraintendetemi, sono molto pro-immutabilità, ma se userete oggetti mutabili, il consiglio di Scott Meyers aiuta a mantenerlo altamente coeso.

score 1 · Answer 2

a.fn(b) e fn(a,b) hanno esattamente la stessa potenza semantica dell'utente. La differenza è la capacità del primo di accedere ai privati. (Questo è un problema con gli sviluppatori di A, non proprio un problema degli utenti di A)

Quando si utilizza una programmazione generica, la funzione libera può avere l'attivazione di SFINAE e può avere una sintonizzazione più flessibile tra diversi tipi (ed è ciò che sta guardando Meyers)

Quando si impiega OOP puro basato su puntatore, di solito si preferisce chiamare membro a significare "sostituzione dell'oggetto runtime al lavoro". Soprattutto per Javanese nativi

Ma sono entrambe convenzioni a causa della storia, non cambiando davvero così tanto. Puoi sempre trasformare l'uno con l'altro con un costo di una chiamata inline .