Come spiegare DependencyProperty usando l'analogia del mondo reale?

Mi piace la risposta di Dave, ma dirò che questo è il modo in cui solitamente penso a DependencyProperties, almeno con Silverlight (penso che WPF sia simile):

• Se vuoi creare qualcosa che può essere target di un binding, devi creare una classe che implementa INotifyPropertyChanged.
• Se vuoi creare qualcosa che puoi definire in XAML e associare a qualcosa, devi creare una derivata di DependencyObject con DependencyProperties.

Ottenere questa comprensione è stato un punto di svolta nella mia capacità di progettare le cose in Silverlight in modo appropriato.

Da una risposta al mio post su StackOverflow di Kent Boogart :

Affinché una proprietà sia la destinazione di un'associazione, tale proprietà deve essere una proprietà di dipendenza. WPF (e Silverlight) usano le proprietà di dipendenza come mezzo per tenere traccia delle modifiche, supportando la precedenza del valore (per le animazioni e simili) e un sacco di altre cose utili. Nota che ho detto "bersaglio". L'origine di un'associazione può essere qualsiasi oggetto vecchio che supporta la notifica di modifica.

Questo piccolo bocconcino di conoscenza mi ha davvero aiutato. Quindi usalo se vuoi associare le proprietà ai tuoi UserControl personalizzati.

Per un'analogia del mondo reale, suppongo che andrei con una voce della rubrica.

Ci sono molte persone / numeri di telefono nel mondo, ma possono essere trovati da chiunque pubblichi il tuo numero nella rubrica.

Allo stesso modo, ci sono molte proprietà regolari che esistono e gli elementi che ne sono a conoscenza sanno che esistono e possono usarle, ma una DependencyProperty è qualcosa che l'intera applicazione è a conoscenza e può cercare quando necessario.