A presentation layer is under no obligation to use the same abstractions as the model it uses. Indeed there is a lot of power in using different abstractions.
It sounds like the abstraction you need in your presentation is "offer card" and isn't the same as an offer or a merchant. Allow this difference to be reflected in your code. Don't create an "offer card" model object. Have an "offer card" presentation object that takes messages from the model objects. It can then populate a UI with that information.
Going the other way can work of course. But it really has exactly the same problem inheritance does. Sure you get a new layer and some indirection but the interface is the same so the level of abstraction is the same. That is very limiting. Prefer new abstractions in new layers to old abstractions.
Can you please elaborate on " Have an "offer card" presentation object that takes messages from the model objects."? - CodeYogi
Sure thing. In this diagram your model is now Business Rules.
Here's an example where your "offer card" presenter doesn't know about or hold a reference to your offer or merchant models. All your presenter has to do is implement the interfaces they talk to. When they talk to you you translate what they say into things the UI can display.
As the presenter, you don't ask the model any questions at all. You don't ask the UI any questions. You get told to do things and you tell other things to do things.
This is tell, don't ask. It insures as you go through a layer you have the full benefits of polymorphism, of being object oriented, and have the right to abstract anyway you feel like abstracting.
It's amazingly powerful. But to take full advantage it demands you be willing to abstract at every layer. This means thinking of lots of names. Thankfully, you'd already done the hard work: "Offer card". Indeed, as I've mastered structuring my code in any conceivable way I've come to find what limits me more than anything else is thinking of a good name.
If you're wondering exactly what "talk to" means here's how Uncle Bob puts it:
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
To put that a little simpler
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
A very good existing answer about this comes from @zapl