Less code, as long as it's readable is better than more code
From a code size point of view I always go with the solution that requires the least amount of code that is still readable and maintainable. Less code means less chance for defects and less code to maintain.
Multiple Inheritance is not a good choice for Composition
From a design stand point I would not use multiple inheritance the way you describe for the following reasons:
- attribute/method overloading
You are changing the way data
is behaving in the different classes. While it doesn't directly violate the Open/Closed Principle of OO with the initial implementation, any changes in the future have a good chance of modifying the behaviors in one or more locations. You are also relying on behavior pulled through super
which will only works correctly if you have the base classes ordered correctly in the class definition.
- fragile tight (vertical) coupling
Relying on the class definition to specify the correct ordering of classes create a fragile system. It's fragile because you can't choose classes that have particular interfaces defined, you actually have to know the implemented logic so the super
calls get executed in the correct order. It's also an extremely tight coupling as a result. Since it's using class inheritance we also get vertical coupling which basically means there are implicit dependencies not just in individual methods, but potentially between the different layers (classes).
- multiple inheritance pitfalls
Multiple inheritance in any language often has many pitfalls. Python does some work to fix some issues with inheritance, however there are numerous ways of unintentionally confusing the method resolution order (mro) of classes. These pitfalls always exist, and they are also a prime reason to avoid using multiple inheritance.
Alternatives
Alternatively I would leave data source specific logic in the classes (ie. *_CacheDB). Then use either decorator or functional composition to add the generalized logic to automatically apply the transformations.
A decorator is basically just a function.
Example in Common Lisp:
(defun attributes (keywords function)
(loop for (key value) in keywords
do (setf (get function key) value))
function)
In above the function is a symbol (which would be returned by DEFUN
) and we put the attributes on the symbol's property list.
Now we can write it around a function definition:
(attributes
'((version-added "2.2")
(author "Rainer Joswig"))
(defun foo (a b)
(+ a b))
)
If we want to add a fancy syntax like in Python, we write a reader macro. A reader macro allows us to program on the level of s-expression syntax:
(set-macro-character
#\@
(lambda (stream char)
(let ((decorator (read stream))
(arg (read stream))
(form (read stream)))
`(,decorator ,arg ,form))))
We then can write:
@attributes'((version-added "2.2")
(author "Rainer Joswig"))
(defun foo (a b)
(+ a b))
The Lisp reader reads above to:
(ATTRIBUTES (QUOTE ((VERSION-ADDED "2.2")
(AUTHOR "Rainer Joswig")))
(DEFUN FOO (A B) (+ A B)))
Now we have a form of decorators in Common Lisp.
Combining macros and reader macros.
Actually I would do above translation in real code using a macro, not a function.
(defmacro defdecorator (decorator arg form)
`(progn
,form
(,decorator ,arg ',(second form))))
(set-macro-character
#\@
(lambda (stream char)
(declare (ignore char))
(let* ((decorator (read stream))
(arg (read stream))
(form (read stream)))
`(defdecorator ,decorator ,arg ,form))))
The use is as above with the same reader macro. The advantage is that the Lisp compiler still sees it as a so-called top-level form - the *file compiler treats top-level forms specially, for example it adds information about them into the compile-time environment. In the example above we can see that the macro looks into the source code and extracts the name.
The Lisp reader reads the above example into:
(DEFDECORATOR ATTRIBUTES
(QUOTE ((VERSION-ADDED "2.2")
(AUTHOR "Rainer Joswig")))
(DEFUN FOO (A B) (+ A B)))
Which then gets macro expanded into:
(PROGN (DEFUN FOO (A B) (+ A B))
(ATTRIBUTES (QUOTE ((VERSION-ADDED "2.2")
(AUTHOR "Rainer Joswig")))
(QUOTE FOO)))
Macros are very different from reader macros.
Macros get the source code passed, can do whatever they want and then return source code. The input source does not need to be valid Lisp code. It can be anything and it could be written totally different. The result has to be valid Lisp code then. But if the generated code is using a macro too, then the syntax of the code embedded in the macro call could again be a different syntax. A simple example: one could write a math macro which would accept some kind of mathematical syntax:
(math y = 3 x ^ 2 - 4 x + 3)
The expression y = 3 x ^ 2 - 4 x + 3
is not valid Lisp code, but the macro could for example parse it and return valid Lisp code like this:
(setq y (+ (* 3 (expt x 2))
(- (* 4 x))
3))
There are many other use cases of macros in Lisp.
Best Answer
Yes, it probably does, but it proprably retains a reference to the original
get(self)
definition.Python decorators are nothing more than a callable themselves (a function, or a class instance with a
__call__
method). Whatever that callable returns is used as the definition for the decorated function instead.If I define a simple no-op decorator like this, that means that I replace the original with.... the original:
The
@
symbol used for decorators is syntactic sugar, you could also write it as:In the case of the tornado
asynchronous
decorator, the decorator probably returns a deferred handler, to handle the decorated function asynchronously, keeping you, the programmer of a tornado-based application, from having to remember the intricacies of how to do that, time and again. In short, it let's you focus on the details of your application instead.