¿Tiene sentido para proporcionar captador de referencia no const

Question

A veces necesito para exponer algunos de los miembros de la clase. Por ejemplo, en el siguiente ejemplo class Mechanic pueden requerir el acceso directo al componente Engine. He leído muchas veces que todos los campos deben tener acceso a los mutantes (descriptor de acceso) métodos 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;
}

motor pública componente más simplemente haciendo:

class Car
{
    public:
        Engine engine;
}

También puede reemplazar con public protected si no lo hace como en este ejemplo. En la vida real tiene algo simillar en Java cuando se trata de System.in o System.out. Parece que, para cumplir plenamente en lo que dicen algunas personas, lo que se necesita para 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

punto razonable

he encontrado para proporcionar tales getter. Esto hace que la integración de su software más fácil (por ejemplo, cuando se desea traducir a otro idioma de interfaz y se unen ITB).

Answer 2

Se puede ser útil cuando el valor va a devolver es en realidad 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

getters explícitos y definidores puede ser excesivamente burocrático; que depende de su situación.

La principal razón citada por tener funciones get y set es que aísla los clientes de su clase de posibles variaciones de aplicación en el futuro (por ejemplo, considere lo que pasaría si decide generar un objeto Engine a la carta (en lugar que el uso de una variable miembro), o decidir ocultar detrás de un puntero inteligente o algún otro recipiente).

Si su clase si es muy simple (por ejemplo, cerca de ser un POD ) y es improbable que el cambio , entonces puede no valer el faff de tener que poner en práctica los métodos get y set.

Sin embargo, para responder a su pregunta, un no constante captador probablemente no tiene mucho sentido. Su prototipo de captador debe ser Engine & engine() const; de lo contrario no será capaz de llamar en los objetos const Car.

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 necesidad clase no volver a compilar. Pero si usted tiene un campo público y más tarde decide hacer un captador, todo el código debe volver a compilar. Aparte de eso, no veo ninguna razón práctica seria para que su variable privada. Sin embargo tenga en cuenta que todo esto se cumple si y sólo si usted tiene que proporcionar una manera para que los usuarios externos para obtener una referencia al motor. Si es posible diseñar el software para que este tiene que ser eliminada en absoluto, que sería mejor.

Answer 5

Como me pasó a ser educado en poco tiempo, captadores y definidores olor del mal diseño. Pero, si quieres que de esa manera, que proporciona funciones para obtener y m_engine conjunto (Definido por el usuario) en lugar de exponerlo (Usted tiene ninguna intervención) significa que usted tiene un plug-in punto para futuros cambios.

Answer 6

Para mí tiene sentido aquí:

image(i,j) = 234;

Answer 7

En lugar de pensar acerca de la exposición de los miembros privados de una clase piensa más en la línea de la llamada a métodos en esas clases. Leí un interesante artículo de Java, qué métodos getter y setter son mal, que se aplica tanto a C ++ como lo hace a Java.

Answer 8

Sí, tiene sentido - para el mantenimiento, validación y consistencia

.

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

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

Finalmente, el código será consistente: no tendrá que abrir la cabecera para conocer la visibilidad de miembros - que acaba siempre sabe. Esto también es útil con las 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, por ejemplo:. Engine.fix(const Mechanic&), como supongo que se modificará el estado de la Engine

La idea original de la utilización de clases era atar juntos los datos con sus funciones de acceso. Si lo hace incubadora o getter que simplemente devuelve un interno de datos, significa que sus datos no se ata junto con su funcionalidad de acceso: la clase no es completa.

solo quiere exponer datos nuevos, que emite una clase . Por ejemplo Car.get_exhaust() y la Car no tiene el tubo de escape, sólo se produce, cuando se pregunta por lo. ;)

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á Mechanic.add_working_hour(0.5) digamos. XD