Lets say I’m displaying a bunch of data (model) using a View class for rendering. However, a lot of the data has sub-data (models) complicated enough to require separate rendering classes.
In my design, a View class has a model which it is rendering, and has many children Views which display the sub-data. In some cases, A View, while containing a model, may not have anything to render and serves more as a wrapper for it children.
However, if you have very complex data and your sub-views have subviews,this design results in deeply nested method calls. Some methods are simply passing information to view classes who may do nothing with it except pass it to their children. This seems inefficient, so I figured there might to be a pattern or something that solves this more elegantly.
4
Looks to me like you’re not really separating the model and the view, while being in a situation where such a separation is exactly what you need.
If “a View class has a model which it is rendering” then there’s really no separation between them, you can just make one class for that. I’m not saying that there’s anything inherently wrong with that, for example the Spring (Web) MVC framework has a ModelAndView class which can contain references to a (composite) model and a view. I’m just thinking that in your case it would be better if you’d externalize the relation between model and view: have your Model classes completely separated from your View classes, and then have some sort of manager that decides what View is used to display what Model at a given time.
Then make each of these as granular as needed to be able to reuse them, i.e. if you have some piece of model and a certain way to display it which is repeated as part of multiple views (but at the same time that piece of Model is also needed to be displayed differently in other views) then make Model and View classes for each of these situations, and have a manager decide with what view that model should go depending on the current context (parent view, request, etc).
2
On the one hand we teach ourselves to use design patterns and common sense design techniques, from which emerges the ideal of designing close to conceptual models, and, on the other hand, we’re concerned when our resulting models become deep. And we shouldn’t be.
If, conceptually, your views are aggregations of other views, then I see no problem with nested structures and the resulting delegation model. I see no problem with views delegating as part of fulfilling their role, as long as their interface is consistent with their purpose and speaks at a consistent level of abstraction.
Let me restate this. If you were to explain your view to colleagues, and the explanation best describes the view in terms of other views, then that is what your code should be like.
In fact, views that delegate may be simply working to realize the Law of Demeter (not something to go fanatic about, but definitely something nice to recognize in your designs).
I should say that I apply the above principles in my user interface code with good results. Event handling can become verbose, but you have EventBus to the rescue.
Assuming you have a sufficient templating language that allows for mixing and matching your templates, you should break out each relevant piece of your model into its own template which can be used to make a composite view.
For instance, you may have a Book model, which in turn has data for Bookmarks, perhaps some Highlights, and maybe PageNotes. Now each of these should have their own template that renders the content in a meaningful way, and this should be achieved by passed in only the relevant data into the template.
Why would one want to take this approach? It allows you to separate your concerns. You model should be used to marshal your data and move it from point A to point B, and your view should simply render it for consumption.