Movatterモバイル変換


[0]ホーム

URL:


PEP 245

Alex Martellialeaxit at yahoo.com
Thu Apr 5 06:03:52 EDT 2001


"Remco Gerlich" <scarblac at pino.selwerd.nl> wrote in messagenews:slrn9co78i.70t.scarblac at pino.selwerd.nl...    [snip]> Common practice in Python is to do not even that, but just use the objectas> given. If it doesn't have the methods then there will be an exception.> Heavy unit testing is necessary anyway.Sure.  But interfaces happen a lot BETWEEN units -- thus, theyyield less readily than one might hope for to the (excellent,indispensable, splendid) practice of heavy unit-testing."Just go ahead and try to use it, possibly catch resultingexceptions" is good in many cases, but it causes problemswhen state is being modified by certain methods... and thenanother method is missing, so the exception leaves statein some in-between, inconsistent state.  "rolling back"such partial, incomplete state alterations is generally notan easy task.Being able to ask the object about conformance to the*whole* protocol you need BEFORE you start altering statesure helps!  It's no complete solution, because theobject itself may be buggy -- it may BELIEVE it isconformant to protocol XYZ, but be wrong about it --but THAT is what unit-testing on the object should becatching... that it IS correctly implementing thoseprotocols (contracts, interfaces, concepts) it saysit's implementing.There is an unfortunately-large body of experience onthis problem, which is due to the frequent violation,by the designers of COM interfaces, of the important"interface segregation principle" (see, for example,http://www.objectmentor.com/publications/isp.pdf).When an interface is too fat, an object that purportsto 'implement' it may, in fact, often implement just a_subset_; client-code attempts to call methods thatARE in the interface, but that the object does notfully implement, will raise some kind of exception.An interface with 20 methods has over a millionpossible subsets -- even considering each method asonly "entirely implemented" or "not implemented atall".  It's not really sensible to expect clientcode to cope with every subset, or even be testedfor all of them; checking may well not be feasible,as it's often the case that there is no idempotentway to verify that a method is in fact, not just'present', but implemented in a way that can betried without undesired state-altering side effects.Having +slim+, usable interfaces _and a way toquery for conformance to them (without, of course,altering state if conformance is not present)_ isa far better situation.  "One method at a time" isjust very rarely the optimal "granularity" (justas having methods come in chunks of 20 or so isquite rarely what one actually _wants_!).  Thiscan be worked around (as evidenced by the hugeamount of working COM client-code that manages tomore-or-less survive a world full of fat, partiallyimplemented interfaces:-), but it's a real waste ofprogramming effort to have to do it again and againand again and...Alex


More information about the Python-listmailing list

[8]ページ先頭

©2009-2025 Movatter.jp