Un livello di presentazione non ha l'obbligo di utilizzare le stesse astrazioni del modello che usa. In effetti c'è molto potere nell'usare astrazioni diverse.
Sembra che l'astrazione di cui hai bisogno nella tua presentazione sia "carta offerta" e non sia la stessa offerta o mercante. Consenti a questa differenza di essere riflessa nel codice. Non creare un oggetto modello "carta offerta". Avere un oggetto di presentazione "scheda offerta" che accetta i messaggi dagli oggetti del modello. Può quindi popolare un'interfaccia utente con tali informazioni.
Andare dall'altra parte può funzionare, naturalmente. Ma in realtà ha esattamente lo stesso problema ereditario. Certo, ottieni un nuovo livello e qualche riferimento indiretto, ma l'interfaccia è la stessa, quindi il livello di astrazione è lo stesso. Questo è molto limitante. Preferisci le nuove astrazioni nei nuovi livelli alle vecchie astrazioni.
Can you please elaborate on " Have an "offer card" presentation object that takes messages from the model objects."? - CodeYogi
Certo. In questo diagramma il tuo modello ora è Business Rules.
Eccounesempioincuiiltuopresentatoredella"scheda offerta" non conosce o conserva un riferimento alla tua offerta o ai modelli di commercianti. Tutto ciò che il tuo relatore deve fare è implementare le interfacce con cui parlano. Quando parlano con te traduci ciò che dicono in cose che l'interfaccia utente può visualizzare.
Come relatore, non fai nessuna domanda al modello. Non chiedi all'interfaccia utente domande. Ti viene detto di fare cose e dici ad altre cose di fare cose.
Questo è segnala, non chiedere . Assicura che mentre attraversi un livello hai tutti i benefici del polimorfismo, di essere orientato agli oggetti e avere il diritto di astrarre comunque ti senti come se stessi astrattamente.
È incredibilmente potente. Ma per trarne il massimo vantaggio è necessario essere disposti ad astrarre a ogni livello. Questo significa pensare a molti nomi. Per fortuna, hai già fatto il duro lavoro: "Offerta carta". In effetti, dal momento che ho imparato a strutturare il mio codice in qualsiasi modo immaginabile, sono arrivato a scoprire cosa mi limita più di ogni altra cosa è pensare a un buon nome.
Se ti stai chiedendo esattamente cosa significa "parlare", ecco come lo dice lo zio Bob:
You separate the UI from the business rules by passing simple data structures between the two. You don’t let your controllers know anything about the business rules. Instead, the controllers unpack the HttpRequest object into a simple vanilla data structure, and then pass that data structure to an interactor object that implements the use case by invoking business objects. The interactor then gathers the response data into another vanilla data structure and passes it back to the UI. The views do not know about the business objects. They just look in that data structure and present the response.
Robert C Martin
Per dirla in modo un po 'più semplice
The important thing is that isolated, simple, data structures are passed across the boundaries. We don’t want to cheat and pass Entities or Database rows. We don’t want the data structures to have any kind of dependency that violates The Dependency Rule.
Robert C Martin
Una buona risposta esistente al riguardo è fornita da @zapl