Software patterns for frameworks [closed]

Question

I am currently doing some research about software patterns and about architectural patterns for frameworks specifically.

Google is not really showing off for this topic, so I am curious which patterns would you consider specificially important for the architecture of frameworks? I am focusing on frameworks for web, mobile and desktop software, such as Rails, UIKit, etc.

Answer 1

I'm hard pressed to think of a GoF design pattern that's either inappropriate for use in a framework or most appropriate for use in a framework. Patterns and frameworks are orthogonal issues -- if a pattern is useful, it can be useful in a framework. Conversely, if a pattern is useful in a framework, there's no reason that it can't also be put to use outside a framework. Frameworks are just a way to package your code.

Patterns and frameworks are both meant to be reusable, so there's some common purpose in the two ideas and frameworks often make heavy use of patterns. Indeed, a great deal of the benefit of understanding design patterns is that it makes it much easier to understand new frameworks as you encounter them. That said, I don't know of any design patterns that are intended specifically for frameworks.

Answer 2

My first question would be "why are you building a framework?"

Surely there has to be something sub-optimal, missing, broken, or otherwise defective in the existing frameworks even if that something is just that they don't look at the world the way you do (and there is nothing wrong with building a framework to solve a problem domain "your way"--that can lead to a lot of illumination in how to approach problems both for the authors and the users of the framework).

Assuming there is an answer to that question (if there isn't, there is no reason to build the framework at all), then the answer should guide your architecture decisions. There is a lot of wrong-headedness in terms of how design patterns are viewed. They are no panacea. They do not solve problems. They are a way for software engineers to discuss common implementation strategies--but the implementation strategy is derived from what is being implemented.

Perhaps a good way to make this more clear would be to break down some common design patterns.

For an MVC framework, the guiding pain point is that you want a clear division of code--a good separation of concerns. Maintainability and refactorability. For an ActiveRecord ORM, the idea would be to abstract away as much of the database dealings as possible, allowing the users to think in purely object-oriented terms. And so on.