I’m trying to get a presentation together for Work on Oslo. I was thinking, what do I cover? MSchema is very conceptually small. MGrammar is uber-geeky. The repository should, for the most part, be a black-box. Quadrant isn’t in the CTP. So what’s left?
Why Oslo Matters. In trying to figure out why Oslo matters, I’m starting to put together a few examples of situations where Oslo should be the “default implementation” for which you reach. In addition, I want a few pithy sayings or platitudes that help developers use Oslo to it’s fullest.
What am I talking about? In OO, they say, “Favor composition over Inheritance”. If a piece of your application is “Highly algorithmic” or involves “Massive Data Structures” you should start by thinking functional programming FIRST.
When do you reach for Oslo?
Few “types” but each instance a special flower.
In a rules engine, there are few rule types but each type could have many instances. These two attributes may not be present. This attribute is only allowed if a certain entity is present and less than six months old. etc.
Type Hierarchy is out of control
The more concrete types you have, the more likely you need to sit down and think about WHY the types are important. If you just want to say, “Shinbone connected to Anklebone and Kneebone”, then you’d probably be better off define the connections in data and only have a “Bone” class that knows if the Hipbone can actually connect to the Thighbone because it has a modeled schema.
Algorithm/Workflow always changes
Lets say you’re a car insurance company. You partner with several rental organizations to provide replacements to your customers. The general flow of your rental approval process is the same, but maybe Hertz and Enterprise need an up front deposit and Alamo doesn’t because you’re a corporate account. These differences can be captured with data, and a workflow (yes, even a WF workflow) can be built up at run time depending on which is closest to the customer’s location.
Agile says to hold off on making a descision until the last responsible moment. What if that moment is after you’re done programming? In the most extreme cases, you can alter or extend a program by adding only data. In Neverwinter Nights, the first one, you could add classes just by editing some configuration files. You could add spells and monsters by combining art that already existed with some data to make something new, just for your story or for the heck of it.
How do you Think in Oslo?
Favor Variance by Data over Variance by Implementation
Variance by data means there is no difference between a drug and a treatment. Both are prescribed by a doctor. Both cost. Both have to be approved by insurance. How they travel through the system is mostly the same, but where things change, you can ask if it’s a drug and do drug things.
To be slightly more dorky, In D&D 4th edition the difference between a fighter and wizard are, for the most part, the powers to which they have access.
Favor Composition by Data over Composition by Implementation
This is harder for me to explain. Let’s say we have a workflow for our rental car example. If we capture our workflow in data, then we can use that data to build up the forms that need to be shown to the insurance claims clerk at any given step. We don’t create a wizard for Alamo, and a wizard for Hertz. We create a meta-wizard that uses the data to create wizard screens when needed. That way, when we finally get a contract with Rent-a-Wreck, we don’t have to create a wizard for them, we just model and implement the workflow and the wizard is generated.