It makes testing more complex Python code an awfully funny affair, mostly awfully.
Has it to do with this? Especially the 'comments' remarks? How do we know what client code needs to know?(?)
A disadvantage of policies in their current incarnation is that the policy interface doesn't have a direct, explicit representation in code
, but rather is defined implicitly, via duck typing
, and must be documented separately and manually, in comments
. The main idea is to use commonality-variability analysis to divide the type into the fixed implementation and interface, the policy-based class, and the different policies. The trick is to know what goes into the main class, and what policies should one create. The article mentioned above gives the following answer: wherever we would need to make a possible limiting design decision, we should postpone that decision, we should delegate it to an appropriately named policy.
In fairness, if you don't implement your abstract functions you get a compiler error whereas with DT you might give the server a chicken (chicken don't quack in general) and then I suspect we get an unreadable compiler at best (no concepts
in C++) or an even more scary run-time error in Python at worse (I don't know Python).