¿Tiene sentido proporcionar getter de referencia no const

Question

A veces tengo que exponer algunos de los miembros de la clase. Por ejemplo, en el siguiente ejemplo, class Mechanic puede necesitar acceso directo al componente Engine. He leído muchas veces que se debe acceder a todos los campos mediante métodos de mutador (acceso) debido a varias razones. Pero ¿hay alguna ventaja en la prestación de captador de referencia no const:

class Car 
{ 
    public: 
     Engine & engine() 
     { 
      return m_engine; 
     } 

     //as a consequence you will also need to provide const version 
     const Engine & engine() const 
     { 
      return m_engine; 
     } 

    private: 
     Engine m_engine; 
} 

sobre pública componente del motor simplemente haciendo:

class Car 
{ 
    public: 
     Engine engine; 
} 

También puede reemplazar con publicprotected si no te gusta este ejemplo. En la vida real tiene algo simillar en Java cuando se trata de System.in o System.out. Parece que, para ser totalmente compatible con lo que algunas personas dicen, necesitarías realizar llamadas como System.getInstance().getOut().println("hello world"). No veo ningún beneficio excepto un montón de código burocrático en tales casos.

Answer 1

He encontrado un punto razonable para proporcionar tal getter. Facilita la integración de su software (por ejemplo, cuando desea traducir la interfaz a otro idioma y enlazar ABI).

Answer 2

Pueden ser útiles cuando el valor que está devolviendo está realmente en el montón.

template<class T> class Singleton 
{ 
private: 
    static T* m_pSingleton; 

public: 
    T& getSingleton() { assert(m_pSingleton); return(*m_pSingleton); }; 

}; // eo class Singleton 

Answer 3

Para mí tiene sentido aquí:

image(i,j) = 234; 

Answer 4

Una ventaja de proporcionar un captador es que cuando y si se decide cambiar la forma en que funciona getter, el código que utiliza esta clase no tiene por qué ser recompilado Pero si tiene un campo público y luego decide hacer un getter, todo el código debe ser recompilado. Aparte de eso, no veo ninguna razón práctica seria para hacer que tu variable sea privada. Sin embargo, tenga en cuenta que todo esto se cumple si y solo si debe proporcionar una forma para que los usuarios externos obtengan una referencia al Motor. Si es posible diseñar el software para que esto se elimine del todo, sería mejor.

Answer 5

Buscadores y establecedores explícitos puede ser excesivamente burocrático; Eso depende de tu situacion.

La principal razón para tener funciones getter y setter es que aísla a los clientes de su clase de posibles cambios en la implementación en el futuro (por ejemplo, considere qué pasaría si usted decide generar un objeto Engine a pedido (en lugar de usar una variable miembro), o decide ocultarlo detrás de un puntero inteligente o de algún otro contenedor).

Si su clase es muy simple (por ejemplo, cerca de ser POD) y es poco probable que cambie, puede que no valga la pena tener que implementar getters y setters.

Sin embargo, para responder a su pregunta, un getter no const probablemente no tenga mucho sentido. Su prototipo getter debe ser Engine & engine() const; de lo contrario, no podrá llamarlo al constCar objetos.

Answer 6

En lugar de pensar en exponer a miembros privados de una clase, piense más en las líneas de métodos de llamadas en esas clases. Leí un interesante artículo de Java, Why Getter and Setter Methods are Evil, que se aplica tanto a C++ como a Java.

Answer 7

Como me enteré de que me educaron recientemente, los buscadores y los incubadores huelen a mal diseño.Pero, si lo desea de esa manera, proporcionar funciones para obtener y configurar m_engine (definido por usted) en lugar de simplemente exponerlo (no tiene intervención) significa que tiene un punto de complemento para cambios futuros.

Answer 8

sí, tiene sentido - para facilidad de mantenimiento, validación y coherencia.

puede que tenga que cambiar muchos aspectos de la clase en el futuro, siempre que un acceso puede ayudar a minimizar la rotura del código del cliente.

puede introducir toda la lógica de validación que necesita aquí, para asegurar que el motor es un puntero válido, no está en un estado inutilizable, etc.

finalmente, su código será consistente: no tendrá para abrir el encabezado y conocer la visibilidad del miembro, siempre lo sabrá. esto también es útil con plantillas.

Answer 9

En este caso sería más bien necesita una función Car.fix(const Mechanic&) que a su vez le da al motor a la Mechanic, decir: Engine.fix(const Mechanic&), como supongo que se modificará el estado de la Engine.

La idea original de utilizar clases era unir los datos con sus funciones de acceso. Si lo hace setter o getter, que simplemente devuelve una información interna, significa que sus datos no están vinculados con su funcionalidad de acceso: su clase no está completa.

Desea solamente exponer los datos nuevos que una clase emite. Diga Car.get_exhaust() y el Car no tiene el escape, solo lo produce, cuando usted lo pide. ;)

O Fire Riefle.fire() mientras que hay acceso para Riefle::Trigger será fijado por el mecánico de este modo: Trigger.fix_by(Mechanic) y luego el fix_by llamará decir Mechanic.add_working_hour(0.5). XD