
Framework Patterns - luord
https://blog.startifact.com/posts/framework-patterns.html
======
lioeters
Excellent article describing common design patterns used by frameworks, with
examples and trade-offs/drawbacks discussed.

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".)

~~~
karambir
I agree totally with "Metaclass based registration" as I have seen the same
with Django Models. It took some time initially to grasp what(and when) is
happening under the hood. Even now, I find it hard to make newcomers
understand how it all works. I have taken 2 sessions with my current interns
and still they get lost.

~~~
lioeters
From the article:

> 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.

~~~
ses1984
This is handwaving a bit, you still have to manually create the migration that
results from your model code change, and also apply the migration.

It's "automatic" because you just have to issue a single command for each, and
django generates the migration from your code and settings.

------
ChrisMarshallNY
Great article.

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>

------
quangv
So then React is a framework?

~~~
PaulHoule
I would say yeah.

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.

