12 comments

• 

  Kevin Teague

  9 months ago

  Nice article. A few minor points:
  
  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
  reply
• 

  Dhananjay Nene

  9 months ago

  Thanks Kevin for the detailed comment and suggestion. I retained all the names from Robert Martin's examples which were C++ based since it would allow interested users to be able to map the code snippets into his examples as well. Thats where ButtonImpl comes from.
  
  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.
  reply
• 

  bearophile

  9 months ago

  shapes.sort(key=lambda s: order.index(type(s)))
  for shape in shapes:
  shape.draw()
  reply
• 

  Dhananjay Nene

  9 months ago

  Thanks.
  reply
• 

  bearophile

  9 months ago

  order = [Circle, Square] # the order in which to draw the shapes
  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()
  reply
• 

  bearophile

  9 months ago

  I also suggest to take a look at ABC of Python3.
  reply
• 

  Dhananjay Nene

  9 months ago

  Didn't understand what you were referring to. Are you suggesting that I need to revisit some of my basic understanding or are you pointing me towards some document or source of information ?
  reply
• 

  bearophile

  9 months ago

  Sorry for not being clear. In one answer of mine I have shown you that you have to use s.__class__, because type(s) is broken/wrong there.
  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/
  reply
• 

  bearophile

  9 months ago

  I have created a D version too:
  
  http://www.digitalmars.com/webnews/newsgroups.p...
  reply
• 

  Paddy3118

  9 months ago

  I would like to reference this from the Wikipedia entry for Duck Typing. It is informative and handles the "static vs Dynamic" language argument admirably. - Paddy.
  reply
• 

  Dhananjay Nene

  9 months ago

  Paddy,
  
  That would be great. I would be pleased with the reference.
  
  Thanks
  Dhananjay
  reply
• 

  Paddy3118

  9 months ago

  It's done. :-)
  reply