> Then we are back to the initial discussion, that is inheriting > implementation vs. implementing interfaces. These are two different things. > If we have to use class inheritance, we will need a abstract class. > However, this is way to rigid as a approach. You end up with a much more > confusing class hierarchy design. Sometimes, you end up being "forced" to > used multiple inheritance, not because the objects are related, but because > they have to support the same interface. Implied interfaces with good documentation can be used when cluttering the class hierarchy is a concern. Also, there are other mechanisms to achieve interface-like behavior. Not that I am a fan of PEP 246, but adapters (QueryInterface approach) could work here. > To explain it better: sometimes objects need to behave in a similar way, by > implementing the same interface; however, they are not intrisecally related > to the point the a common ancestor would be justified. Someone wrote an > example of family with a Python programmer; I dont remember the details but > it does illustrate my point. You are thinking in terms of "explicit" interfaces. :) The difference between inheritance and interfaces is important when you are using the "implementation hierarchy" to discover if an object supports an interface, e.g. if x implements y: I can argue that even if interfaces PEP is adopted, it will be used for documentation purposes only, as no one will be using "implemented" built-in, just like no one checks to see if object has method "doX" before calling obj.doX (). Let's take the family example. There are four participants: Mother, father, and two sons. Each son inherited properties from both the mother and the father (Please keep in mind that this is not a paper on Genetics:). The first son happen to be a musician, and a philosopher. The second son is a programmer, and a philosopher. Let's see their class definitions using the explicit interfaces: class Mother: ... class Father: ... interface Musician: def playViolin (): """""" interface Philosopher: def thinkHard (): """""" interface Programmer: def hackCode (): """""" class Son1 (Mother, Father) implements Musician, Philosopher: def playViolin (self): ... def thinkHard (self): ... class Son2 (Mother, Father) implements Programmer, Philosopher: def hackCode (self): ... def thinkHard (self): ... #Here is some client code s1 = Son1 () s1.playViolin () s1.thinkHard () s2 = Son2 () s2.playViloin () s2.hackCode () for s in [s1, s2]: s.thinkHard () Now let's compare that to the implied interface scenario: class Mother: ... class Father: ... class Son1 (Mother, Father) implements Musician, Philosopher: def playViolin (self): ... def thinkHard (self): ... class Son2 (Mother, Father) implements Programmer, Philosopher: def hackCode (self): ... def thinkHard (self): ... #Here is some client code s1 = Son1 () s1.playViolin () s1.thinkHard () s2 = Son2 () s2.playViloin () s2.hackCode () for s in [s1, s2]: s.thinkHard () As you can see, the only difference between the two examples is interface declarations in the explicit interface example. And as far as I am concerned, XML is a better way to document something like that. -- Alex Shindich mailto:alex at shindich.com Visit http://www.shindich.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: alex.vcf Type: text/x-vcard Size: 194 bytes Desc: Card for Alex Shindich URL: <http://mail.python.org/pipermail/python-list/attachments/20010415/cbb2d3f6/attachment.vcf>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4