4 ms·

Excellent article describing common design patterns used by frameworks, with examples and trade-offs/drawbacks discussed. A framework is defined as "code that

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

karambir 7y ago

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