1. “what”-metadata driven ● problem: you have many behaviours that only differ in parameters or small variants of behaviour ● solution: write metadata & code that derives behaviour from metadata
1. “what”-metadata driven ● problem: you have many behaviours that only differ in parameters or small variants of behaviour ● solution: write metadata & code that derives behaviour from metadata ● benefit: adding new behaviours now means just adding metadata, & in rare cases also overriding classes/functions
2. high-level “what”-code ● problem: you have many behaviours that only differ in the “edges” ● old solution: using inheritance tricks such as template method &c
2. high-level “what”-code ● problem: you have many behaviours that only differ in the “edges” ● newer solution: abstract the algorithm to declarative high-level code & “chain” the overriding behaviour
2. high-level “what”-code ● problem: you have many behaviours that only differ in the “edges” ● newer solution: abstract the algorithm to declarative high-level code & “chain” the overriding behaviour ● benefit: see the big picture & just the relevant details
3. “how”-code abstracted away ● problem: if some code addresses requirements that are obvious & not specific to your app, why should it be there? ● solution: abstract that code in an underlying framework, either yours or someone’s else
3. “how”-code abstracted away ● problem: if some code addresses requirements that are obvious & not specific to your app, why should it be there? ● solution: abstract that code in an underlying framework, either yours or someone’s else ● benefit: simple, small code just for the requirements specific to your app
Example 2: Meteor ● if a user is looking at a list of records, obviously when a new record is added, the user should see it ● & if he changes a record, obviously other users looking at it should see the modification ● so why should you implement this?
Example 2: Meteor ● So what's declarative here? ○ You are left with just declarations: ■ What data the server publishes ■ What data the client subscribes to ■ What data is shown in the UI ● See this list of 8 open-source apps written in Meteor: http://meteorapps.co ○ Except for one they are all well written & worth learning from..