Framework Patterns
blog.startifact.com
blog.startifact.com
A framework is defined as "code that calls your (application) code". Not sure I totally agree, since frameworks that I've built are usually instantiated by the application explicitly. Well, that launch sequence is one of these patterns described.
Here's a table of contents.
- Callback function
- Subclassing
- interfaces
- imperative registration API
- convention over configuration
- metaclass based registration
- language integrated registration
- DSL-based declaration
- imperative declaration
- language integrated declaration
(Nitpick: might want to standardize the capitalization of titles, like "Pattern: Callback Function".)
> When you declare a Django model by subclassing from its Model base class, Django automatically creates a new relational database table for it.
That sounds convenient - but feels like too much implicit behavior for me. I almost always prefer a framework that lets (or forces) the user to explicitly specify operations.
Same with "import-time side-effects". When I find myself providing such a shortcut, I usually wrap it so the user must call it explicitly, to control what/when these effects happen.
It's "automatic" because you just have to issue a single command for each, and django generates the migration from your code and settings.
I'm always a bit ambivalent about assigning "hard and fast rules."
In my mind, a "framework" is...a framework.
Frameworks are structural artifacts. They exist in the corporeal world, as well as CyberWorld. Buildings are constructed over frameworks. Vehicles are constructed over frameworks.
I have been writing SDKs, APIs, frameworks and drivers for a long time.
<opinion type="mine">
I tend to differentiate them (in my head) like so:
DRIVER
Code/binary asset that affords a connection between two levels of a dynamic system; abstracting characteristics of the lower part of the system.
Drivers can exist at many layers; from machine-code to UI. I have written UI component drivers, as well as device drivers.
Drivers tend to be "smaller" projects than frameworks, but there's a lot of similarity between drivers and some types of frameworks.
API
The published specification that defines interaction with a code/binary asset; combined with a minimal level of exposed code to afford access to the API elements.
SDK
A code/binary asset that exists independent of an API, but which affords access to that API; often adding functionality.
I feel that an SDK can def be a framework.
FRAMEWORK
Fairly similar to what was defined. maybe a bit "looser."
This is a set of code assets (not necessarily binary, but it's possible) that can be used as a "seed" or integral component of a code application (small "a," not necessarily a complete executable application -it could be a driver, SDK, operating system or framework).
In my mind, frameworks can be complete, self-contained and closed; possibly exposing only an API as an affordance to access the assets. Cocoa is an example. A framework can also be completely open-ended, and unusable without components provided by the implementor. Classic app frameworks like Qt are examples of this.
It may be open-source, or opaque.
The frameworks that I have written have been fairly large.
I feel that Drupal or WordPress can be considered frameworks, as well as things like Qt or Cocoa.
</opinion>
I think React calls you (render + callbacks) more than you call it in most cases.
Like a library, however, your code is usually kicking things off by calling ReactDOM.render().
I'm sure there are "meta-frameworks" build around react which set up your router in declarative style and call that top level method.