estoy seguro de que todos ustedes estaban en ese momento - la definición de un Q_OBJECT
llevar una tonelada de Q_PROPERTIES
, todos con descriptores de acceso más triviales:Properties QT - sintáctica azúcar o herramientas de desarrollo
class ORM_Customer : public QDjangoModel
{
Q_OBJECT
Q_PROPERTY(QString firstname READ firstname WRITE setFirstname)
Q_PROPERTY(QString lastname READ lastname WRITE setLastname)
Q_PROPERTY(QString phone READ phone WRITE setPhone)
Q_PROPERTY(QString address1 READ address1 WRITE setAddress1)
Q_PROPERTY(QString address2 READ address2 WRITE setAddress2)
Q_PROPERTY(QString houseno READ houseno WRITE setHouseno)
Q_PROPERTY(QString postcode READ postcode WRITE setPostcode)
[... snip ...]
}
con una tonelada de descriptores de acceso todos en busca de esa manera:
QString ORM_Customer::firstname() const { return m_firstname; }
QString ORM_Customer::lastname() const { return m_lastname; }
void ORM_Customer::setFirstname(QString &n) { m_firstname = n; }
void ORM_Customer::setLastname(QString &n) { m_lastname = n; }
Dado que utiliza QDjangoModel meta objeto la introspección, no puedo depender de las propiedades dinámicas aquí (además, me gusta propiedades estáticas) - pregunta es, ¿hay alguna herramienta que me ahorraría el manual ¿labor?
Qt Creator no parece tener la opción de simplemente declarar y definir algunos descriptores de acceso predeterminados y sus respectivas variables privadas. ¿Algo más? Seguramente debe haber molestado a más desarrolladores que solo a mí mismo.
¿O quizás solo hay otro patrón de desarrollo que otros usan?
Sí, eso siempre me ha molestado. Q_PROPERTY siempre me llegó como azúcar. Siempre puede tener un miembro QVariantMap con funciones get/set genéricas. O, si lo prefiere, un 'enum' personalizado con un miembro' QHash '. –
Phlucious
El único caso en el que consideraría Q_PROPERTY es al desarrollar un complemento para Designer. – Phlucious