-
Website
http://blog.dhananjaynene.com -
Original page
http://blog.dhananjaynene.com/2008/09/python-from-java-how-duck-typing-influences-class-design-and-design-principles/ -
Subscribe
All Comments -
Community
-
-
Top Commenters
-
Popular Threads
I think you can further merge the Button class and ButtonImpl class together in the Python example in the Dependency Inversion Principle (DIP) section?
In Python I very rarely see the suffix "Impl" appended to a class name. Since all classes in Python by nature are implementation classes, it makes sense to just leave "Impl" out of the name since it's redundant. The exception to this is existing extensions to the Python language which add "Interfaces" and re-use the class keyword to implement the interface concept out of necessity. In which case there is the strong convention to prefix an Interface class name with a capital I.
The phrasing of "TripBooker which would in turn call interface methods on other interfaces" is a bit fuzzy, since interfaces are only specifications and you can't actually "call interface methods" but instead something like "call methods on an object that provides an implementation of an interface".
You end the dependency inversion principle with, "In terms of the definition of DIP itself - abstractions no longer necessarily have to be implemented. They exist implicitly in the detail classes but are no longer explicitly documented." Python has a saying, "Explicit is better than Implicit", but in cases such as your Python dependency inversion example, the contract between what an object ("self") depends upon and the external object ("self.client") is highly implicit. You can only deduce the interface required by this dependency by inspecting the entire Button class and looking for all uses of "self.client". This is a common critique against using Python in a "large team" project, but there has been interesting work done in allowing you to make this dependency explicit with the Zope Component Architecture (ZCA). The Zope Component Architecture provides an Interface package (zope.interface) which lets you specify a contract (such as "IButtonClient has methods on() and off()") and then make explicit the fact that a class such as Button requires the "self.client" object to provide the IButtonClient interface. In cases where one object depends upon only a single other external object, there it's a common convention in Python to call that external object "context" (so it would be referred to as "self.context").
Zope 3 is a framework that builds upon the Zope Component Architecture, and XML is used to specify the dependencies between components (e.g. configuration and code are kept separate). There are also many who find developing with this strict separation tedious, especially in cases of agile or prototype-based development. In this case the practice of "convention over configuration" has been applied to the configuration aspects, and the configuration is deduced by using Python's powerful introspection capabilities - this technique is called "grokking" and is implemented in the Grok web framework - of which I am a happy Grok user :)
http://wiki.zope.org/zope3/Zope3Wiki
http://grok.zope.org
I did a minor restructuring of the words around DIP TripBooker as well. Thanks for pointing out.
I wasn't aware of explicit contracts using zope.interface and Zope Component Architecture. Definitely something I shall checkout.
for shape in shapes:
shape.draw()
shapes = [Circle(1,1,5), Square(2,4,3), Circle(3,3,7), Square(4,2,4)]
shapes.sort(key=lambda s: order.index(s.__class__))
for shape in shapes:
shape.draw()
The successive answer of mine refers to the Abstract Base Classes of Python3, that are absent from Python2.5, and that may interest you, so you may take a look at them:
http://www.python.org/dev/peps/pep-3119/
http://www.digitalmars.com/webnews/newsgroups.p...
That would be great. I would be pleased with the reference.
Thanks
Dhananjay