Capisco perché è una buona idea codificare su un'interfaccia piuttosto che su una classe concreta. Lo trovo difficile da implementare anche se altri metodi generalmente hanno bisogno di usare le proprietà dell'oggetto dato. Ho preso la parte sbagliata del bastone?
Non vedo perché le proprietà necessitino. Non concentrarsi su ciò che è necessario per eseguire l'operazione, ma piuttosto quali operazioni sono necessarie. I dati necessari per eseguire tali operazioni saranno determinati dalle classi di implementazione.
Ad esempio, hai un'interfaccia Shape . Uno dei metodi in questa interfaccia è getArea() . Tu dici che tutto ciò che è un Shape deve essere in grado di calcolare la sua area - ciò implica che deve avere le proprietà e i membri appropriati per farlo. Se una classe Circle implementa l'interfaccia di forma e richiede un metodo getArea() , ciò implica che (poiché getArea() non prende alcun parametro), che l'istanza Circle deve essere consapevole del suo raggio. Se una classe Rectangle implementa l'interfaccia Shape , ciò implica che in qualche modo deve mantenere la sua lunghezza e larghezza.
Nel caso in cui sia necessario un accesso esterno a una proprietà di un oggetto, è necessario renderlo parte dell'interfaccia. La solita convenzione è di aggiungere i metodi set_foo () e get_foo () per fornire questo accesso.
È abbastanza comune aver bisogno di alcune funzioni getter e setter, ma dovresti pensare all'interfaccia prima di aggiungerne troppe. In particolare, è necessario assicurarsi che la proprietà sia una proprietà della classe, non dell'implementazione. Non esporre dettagli di implementazione al di fuori della classe, solo proprietà che sempre faranno parte di qualsiasi ragionevole implementazione di quella classe.
Pensa alla conformità dell'interfaccia come un passo oltre la sicurezza del tipo. Identifica le cose che sono cambiate e i modi in cui possono essere cambiate, definisci l'interfaccia che le fornisce tutte e poi mentre scrivi all'interfaccia ti assicura che non ti preoccupare confonderai i parametri o le unità di disordine.
È sempre possibile assegnare metadati speciali per "Non influire" o "Non applicabile", stub che eliminano informazioni non necessarie o forniscono valori "predefiniti" generici se l'interfaccia è "sul lato grande". Ma stai meglio se usi interfacce più granulari e più piccole per coprire pezzi più piccoli di funzionalità. Sarà meglio implementare separatamente le interfacce "dati di lavoro" e "configurazione", piuttosto che richiedere l'implementazione di un'enorme interfaccia "dati di input", o persino dividere "dati di lavoro" ulteriormente per varie fonti / tipi, come l'attivazione e lo stato come interfacce separate - classi che hanno bisogno di entrambe, implementare entrambe.