Separate policy from mechanism
I personally don’t like to think it as a rule, just like any other rules or principles, I see it as a tool by which we use it to reason our code structure.
This rule looks a bit abstract, let me give you an everyday experience so you may understand and remember what it means.
Every time I try explaining this to my colleagues, I use the example of the sliding doors at our work building. At work we have a pair of sliding doors when we tap our access card to the sensor, they open. Now, imagine Jon Snow just joined the company, before his first day, the building manager goes: okay, there is a new guy Jon, we have to replace the sliding doors, and put in new ones so his access card can work.
But wait, this is NOT how it is in reality, we don’t replace the sliding doors whenever there is a new employee. Instead, we alter the database of access control to add a new entry for Jon, then we imprint the new access code into the chip. Now the sliding doors are what in Unix refers to as the mechanism — opening/closing operation. On the other hand the access control database is the policy or the place that stores the policy which determines who is allowed or disallowed access. In this case, mechanism and policy are physically separated.
Now, let’s look at another example where mechanism and policy are amalgamated. We don’t need to look afar — the front door of our house. If you are renting or have bought a house, you would know or notice landlord may change the lock between tenancy. And most likely , a new set of locks will be put in when you purchase a house. The reason is the pattern of the key blade (policy) is physically built into the lock (mechanism). Because this physical coupling, when policy changes, mechanism changes as well.
Okay, that’s fine, but how does it translate to programming? Please read the Rule Engine Pattern article for further study.
As always thanks for reading please PR me any suggestions appreciated.
