Seriously, name an item and we can quickly describe some common patterns in them. More interestingly, we can describe different sets of patterns that cover the same item. Depending merely on the vantage of who is looking at it.
I think this is where things get truly difficult in programming patterns. We try to get the one abstraction to rule them all. Not necessarily that easy to do.
Looking for one abstraction to rule them all is is like looking for one word to rule them all. Does it make sense ?
On the train home I thought of a retort to the idea of all of this. When it comes to describing a system, there are really only two things I care about. The inputs and the outputs. Anything that obscures either of these in relation to the other is just going to get in the way at some point.
I used to call programming web pages the act of building a giant Rube Goldberg machine where you mix several inputs into building out a web page. I still feel this way, to an extent, but I am hopeful of simple solutions that do not obscure where data comes in and how it goes out. (If that makes sense.)
Am I the only one to feel that this plethora of nebulous patterns hinder creativity and intelligence more than anything else ? What is the deal really ? I may be missing the whole point but for me it seems to be, summed up : keep as much of the core business logic separated from the interface because one will die sooner than the other. Then the correct model depends a lot on the platform you're building on, and the freedom to try and design new paradigms seems to me a much more valuable asset than trying to force-fit your app into MV-WTH. I feel we don't even remember what constraints these models are here to help optimize. Please tell me if I'm missing something. I eagerly await the day when this will all (MVC and friends) settle down and we will be able to start building on top of all that towards more ambitious architectures.