sono sicuro che tutti voi erano a quel punto - la definizione di una Q_OBJECT
trasporta una tonnellata di Q_PROPERTIES
, tutti con funzioni di accesso piuttosto banali:Properties QT - sintattica di zucchero o di strumenti di sviluppo
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 tonnellata di funzioni di accesso tutti in cerca del genere:
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; }
Dato che QDjangoModel utilizza MetaObject introspezione, non posso contare sulle proprietà dinamiche qui (oltre, mi piace proprietà statiche) - domanda è, ci sono strumenti che mi avrebbero salvato manuale lavoro?
Qt Creator non sembra avere la possibilità di dichiarare e definire solo alcuni metodi di accesso predefiniti e le rispettive variabili private. Qualcos'altro? Sicuramente deve aver infastidito più sviluppatori che solo me stesso.
O forse c'è solo un altro modello di sviluppo che altri usano?
Sì, mi ha sempre infastidito. Q_PROPERTY mi è sempre sembrato uno zucchero. Si può sempre avere un membro QVariantMap con funzioni get/set generiche. Oppure, se preferisci, un 'enum' personalizzato con un membro' QHash '. –
Phlucious
L'unico caso in cui considererei Q_PROPERTY è quando si sviluppa un plugin per Designer. – Phlucious