Movatterモバイル変換
[0]ホーム
idioms for abstract base classes
zooko at zooko.comzooko at zooko.com
Tue Apr 24 16:18:56 EDT 2001
Robin Becker <robin at jessikat.fsnet.co.uk> wrote:>> what's the best way to spell an abstract base class so that> 0) base is B and A inherits from B>> 1) doing B() causes an exceptionYou can see here[1, 2, 3] how I did this in Mojo Nation[4]. I made apure-abstract base class (i.e. an "Interface") named "CommsHandler", anon-abstract base class named "BaseCommsHandler", and various subclasses named"{TCP,Crypto,Dummy}CommsHandler".It was a complete failure. Oh, not the "raising an exception if someone invokesa non-implemented method" part. I just put it assertions, as you can see in theCommsHandler class, and never had to touch it again. (Indeed, nobody *ever*accidentally invoked a non-implemented method as far as I can remember.) Thefailure was the whole idea of having base classes.It turned out that there was no functionality that was actually common to bothCryptoCommsHandler and TCPCommsHandler except for some features (namely, theability to chain together an arbitrarily deep "stack" of comms handlers) whichwe never actually needed.It turned out that in addition to wasting my time implementing a feature that wenever needed, I also made the resulting code hard for my fellow hackers tofollow. Due to the polymorphism and due to the common "parallel inheritancehierarchy" problem, it was very difficult even for *me* to understand howcontrol flowed through the classes, which became a serious problem when I cameback to them six months later in order to evolve and debug them.Eventually, we started just undoing the inheritance -- I changedCryptoCommsHandler to just implement all of its methods instead of using any ofthe ones inherited from BaseCommsHandler, and next time I touch TCPCommsHandlerI'll do the same to it. Then we can nuke DummyCommsHandler (which is only goodfor testing the unused "chaining" feature anyway) and CommsHandler andBaseCommsHandler. It will feel really good to get rid of those after all thetrouble they've caused.I think a wise old monk once said "Choose the right tool for the job, and thenuse the tool in the way it was designed to be used.".Python has dynamic structural typing, which gives rise to rapid prototyping,flexible code re-use, and minimal hindrance to the programmer, as well as toclear designs and readable code. USE the dynamic structural typing, and do notattempt to regress to C++/Java style static/dynamic named types, like I did.(If you *really* want static, name-based typing, then switch to C++, Java,Eiffel, Ada95 or something for the modules that need that kind of style.)In fact, I suspect that premature design, such as the mistake described here, isthe most common error in software engineering (this contradicts the commonbelief that insufficiently farsighted design is the most common problem insoftware engineering). Perhaps part of this is the language used. In assemblyor C, it is harder to see what your design currently *is* and it is harder torefactor your design, so it is easier to get stuck with code that has outlivedany design and has become a mere hairball. But in Python it is easy enough tosee and to change your design that the best approach is usually to do "just intime design". (C++ and Java fall into an ugly "worst of both worlds" camp whereboth too-early and too-late design can bite you.)Please see Kent Beck[5]'s book _Extreme_Programming_Explained[6], which isdelightfully readable and thought-provoking. Do not be put off by the title.I personally ignored the "Extreme Programming" meme for at least a year, becauseI simply didn't want to know about anything so silly and hyped-up as "Extreme"anything. This was a mistake -- actually it is a very sensible and rationalpractice of programming that any experienced Python hacker will find bothfamiliar and refreshing.Regards,Zooko[1]http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/~checkout~/mojonation/evil/common/CommsHandler.py?content-type=text/plain[2]http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/~checkout~/mojonation/evil/common/CryptoCommsHandler.py?content-type=text/plain[3]http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/~checkout~/mojonation/evil/common/TCPCommsHandler.py?content-type=text/plain[4]http://mojonation.net/[5]http://c2.com/ppr/about/author/kent.html[6]http://www.amazon.com/exec/obidos/ASIN/0201616416/103-8730908-0760613
More information about the Python-listmailing list
[8]ページ先頭