Elemento 23 de C++ Efectivo Preferir funciones no miembro no amigo a funciones miembro

El criterio que utilizo es si una función podría implementarse de manera significativamente más eficiente al ser una función miembro, entonces debería ser una función miembro. ::std::sort no cumple esa definición. De hecho, no hay ninguna diferencia de eficiencia en la implementación externa frente a la interna.

Una gran mejora de la eficiencia mediante la implementación de algo como una función miembro (o amigo) significa que se beneficia enormemente de conocer el estado interno de la clase.

Parte de la el arte del diseño de interfaz es el arte de encontrar el conjunto más mínimo de funciones miembro de tal manera que todas las operaciones que desee realizar en el objeto puedan implementarse de manera razonablemente eficiente en términos de ellas. Y este conjunto no debe soportar operaciones que no se deben realizar en la clase. Así que no puedes simplemente implementar un montón de funciones getter y setter y llamarlo bueno.

Creo que la razón de esta regla es que al usar funciones miembro puede confiar demasiado en las funciones internas de una clase por accidente. Cambiar el estado de una clase no es un problema. El verdadero problema es la cantidad de código que necesita cambiar si modifica alguna propiedad privada dentro de su clase. Mantener la interfaz de la clase (métodos públicos) lo más pequeña posible reduce tanto la cantidad de trabajo que tendrá que hacer en tal caso como el riesgo de hacer algo extraño con su privado datos, dejándole con una instancia en un estado inconsistente.

AtoMerZ también tiene razón, las funciones no-miembro no-amigo pueden ser templadas y reutilizadas para otros tipos también.

Por cierto, debería comprar su copia de Effective C++, es un gran libro, pero no intente cumplir siempre con cada elemento de este libro. Diseño orientado a objetos tanto buenas prácticas (de libros, etc.) Y experiencia (creo que también está escrito en C++ efectivo en alguna parte).

Entonces, primera pregunta, ¿no deberían ser miembros que?

No, esto no sigue. En el diseño de clases idiomáticas de C++ (al menos, en los modismos utilizados en C++efectivo), las funciones no-miembro no-amigo extienden la interfaz de clase. Pueden ser considerados parte de la API pública para la clase, a pesar del hecho de que no necesitan y no tienen acceso privado a la clase. Si este diseño no es " OOP " por alguna definición de OOP entonces, OK, idiomatic C++ no es OOP por esa definición.

Estirar el mismo razonamiento a algunos otras funciones en la clase vectorial

Eso es cierto, hay algunas funciones miembro de contenedores estándar que podrían haber sido funciones libres. Por ejemplo, vector::push_back se define en términos de insert, y ciertamente podría implementarse sin acceso privado a la clase. En ese caso, sin embargo, push_back es parte de un concepto abstracto, el BackInsertionSequence, que implementa el vector. Tales conceptos genéricos atraviesan el diseño de clases particulares, por lo que si estás diseñando o implementando tus propios conceptos genéricos que podrían influir en dónde pones las funciones.

Ciertamente hay partes del estándar que podrían haber sido diferentes, por ejemplo std::string tiene demasiadas funciones miembro. Pero lo hecho, hecho está, y estas clases fueron diseñadas antes de que la gente realmente se asentara en lo que ahora podríamos llamar el estilo moderno de C++. La clase funciona de cualquier manera, así que no hay mucho práctico beneficio que puede obtener al preocuparse por la diferencia.

La motivación es simple: mantener una sintaxis consistente. Como la clase evoluciona o se utiliza, varias funciones de conveniencia no miembro no desea modificar la interfaz de clase para agregar algo como toUpper a una clase string, por ejemplo. (En el caso de std::string, por supuesto, no se puede.) La preocupación de Scott es que cuando esto sucede, usted termina con sintaxis inconsistente:

s.insert( "abc" );
toUpper( s );

Usando solo funciones libres, declarándolas amigas según sea necesario, todo las funciones tienen la misma sintaxis. La alternativa sería modificar la definición de clase cada vez que se agrega una función de conveniencia.

No estoy del todo convencido. Si una clase está bien diseñada, tiene un funcionalidad, es claro para el usuario qué funciones son parte de esa funcionalidad básica, y que son funciones de conveniencia adicionales (si existe alguna). Globalmente, string es una especie de caso especial, porque está diseñado para ser utilizado para resolver muchos problemas diferentes; No puedo imaginar que este sea el caso para muchas clases.

Varios pensamientos:

• Es bueno cuando los no miembros trabajan a través de la API pública de la clase, ya que reduce la cantidad de código que:
  • necesita ser cuidadosamente monitoreado para asegurar invariantes de clase,
  • necesita ser cambiado si la implementación del objeto es rediseñada.
• Cuando eso no es lo suficientemente bueno, un no miembro todavía se puede hacer un friend.
• Escribir una función no miembro suele ser menos conveniente, ya que los miembros no están implícitamente en alcance, PERO si se considera la evolución del programa:
  • Una vez que existe una función no miembro y se da cuenta de que la misma funcionalidad sería útil para otros tipos, generalmente es muy fácil convertir la función en una plantilla y tenerla disponible no solo para ambos tipos, sino también para tipos futuros arbitrarios. Dicho de otra manera, las plantillas no miembros permiten una reutilización del algoritmo aún más flexible que el polimorfismo en tiempo de ejecución / envío virtual: las plantillas permiten algo conocido como pato escribiendo .
  • Un tipo existente que tiene una función miembro útil anima a cortar y pegar a los otros tipos que desean un comportamiento análogo porque la mayoría de las formas de convertir la función para su reutilización requieren que cada acceso implícito a un miembro se convierta en un acceso explícito a un objeto en particular, lo que va a ser un tedio más de 30 segundos para el programador....
• Las funciones miembro permiten la notación object.function(x, y, z), que en mi humilde opinión es muy conveniente, expresiva y intuitivo. También funcionan mejor con características de descubrimiento / finalización en muchos IDE.

• Una separación como funciones miembro y no miembro puede ayudar a comunicar la naturaleza esencial de la clase, sus invariantes y operaciones fundamentales, y lógicamente agrupar las características adicionales y posiblemente ad-hoc de "conveniencia". Considere la sabiduría de Tony Hoare:
  
  "Hay dos formas de construir un diseño de software: Una es hacerlo tan simple que obviamente no haya deficiencias, y la otra forma es hacerlo tan complicado que no haya deficiencias obvias. El primer método es mucho más difícil."

  • Aquí, el uso de los no miembros no es necesariamente mucho más difícil, pero tiene que pensar más en cómo está accediendo a los datos de los miembros y los métodos privados/protegidos y por qué, y qué operaciones son fundamentales. Tal búsqueda de conciencia mejoraría el diseño con las funciones de miembro también, es más fácil ser perezoso sobre : -/.

• As la funcionalidad no miembro se expande en sofisticación o recoge dependencias adicionales, las funciones se pueden mover a encabezados y archivos de implementación separados, incluso bibliotecas, por lo que los usuarios de la funcionalidad principal solo "pagan" por usar las partes que desean.

(La respuesta de Omnifarious es una lectura obligada, tres veces si es nueva para ti.)

Creo que sort no se implementa como una función miembro porque es ampliamente utilizada, no solo para vectores. Si la tuvieran como función miembro, tendrían que volver a implementarla cada vez para cada contenedor que la use. Así que creo que es para facilitar la implementación.