|
5 of 5 people found the following review helpful:
2.0 out of 5 stars
A good introduction to COM? Could do (quite a bit) better., 12 Sep 2000
By A Customer
At first I liked the look of this book: the typeface was pleasant to look at, and Mr Harmon seemed to know what he was talking about... and he clearly does know about COM. BUT: to write a good book on a complex subject requires more than mere knowledge of the subject.A good teacher must know how to teach, and a good writer of technical literature must also know how to put things across in a measured, structured and empathic way... Mr Harman falls short here. There is no CD that comes with the book; not even a floppy: sourcecode is available on the net, although it's not where the text says it is... That being the case (and since the sourcecode is not available on CD or floppy) one might think that Mr Harman would choose short, punchy examples... -he does not. The example code listings tend not only to be overlong, but frequently one finds oneself having to get to grips with aspects of coding not directly relevant to the discussion in hand. For instance, one finds Mr Harman complicating his introduction to 'interfaces' with code relating to 'polymorphism', complicating his first proper COM listing with code relating to 'bin-packing' algorithms, complicating his discussion of type libraries with the code for a fairly big and complicated program to READ type libraries that is really not appropriate to an introduction, and so on (consistently). This, it has to be said, is not evidence of a good pedagogical style. It is not even evidence of the kind of basic empathy for the reader that IS a prerequisite on the part of a good technical writer. Let's say that as a reader new to COM, you were still not 100% clear about the meanings of one or more of these words: 'object', 'interface' and 'reference'. Would you then be able to make sense of the following, when the terms have not yet been succinctly defined in the text? 'In the examples presented so far, I've been showing you both object references and interface references as if they work together and are interchangeable. That is not the case. The interface model is an alternative to the reference model. When implementing one or more interfaces in a class, you should manipulate objects of the class using only interfaces. This section shows you how you can get into trouble by mixing the object model and the reference model'. In Chaper 4, on the subject of 'Automation' it seems that Mr Harman has changed tack a little and decided to provide a more concrete (and simple) Delphi example more geared toward the steps one should take in the Delphi IDE to code the example. Fine! But then we find a number of inconsistencies: in Delphi 5 the compiler complains about the 'double' type returned from an automation server object, that we have been asked to specify. OK a little fiddling (if you know how to fiddle it) will get around this one. The next problem one comes across is less insignificant, however: half way through his automation server example Mr Harman changes Class names- one minute he is talking about an IAreaUnitConverter class, and the next he refers to an IUnitArea class (both of which are in fact the same). Clearly he has not checked his code properly, and as a result the reader can only become (more) confused. Did Rhuver Barengi, Derek Benner, or Xavier Pacheco (the 'technical reviewers') actually read this book, and try the examples for themselves? If so then they are being remarkably slack in giving the thumbs-up so easily to material that so clearly falls short from a pedagogic point of view. It is important, in the effective communication of complex ideas, to be able to succinctly stress those points that are most significant, so that the reader can begin to build up a framework, or model, into which subsequent information can be slotted. Mr Harman is not good at this: for example, under the subtitle DispInterfaces his first sentence is 'Somewhere between interfaces and variants are dispinterfaces'. Very clear. Does it become clearer? No: the next sentence reads 'A dispinterface declaration looks almost identical to an interface declaration except it uses the keyword dispinterface instead of interface'... So does he go on to describe the purpose of a dispinterface, then? No, not at all, or only very obliquely. He refers to variants here, but has he defined or clearly described variant types prior to this point (basic rule of teaching: introduce concepts clearly and then use them later as foundations upon which to construct a more complex framework). The answer is 'no, he hasn't' -previously, variants have been touched on in the same 'if you know this already then fine but if you don't know it already don't expect a clear and simple explanation here' style. This is frustrating for those people that the book, is ostensibly at least, aimed at. At risk of labouring the point, here is how Mr Harman introduces the reader to Delphi's ActiveForms. After two short sentences describing what ActiveForms are, in one page of text we are led through using the ActiveForm wizard to create a new ActiveForm. The next fourteen pages consist of code listings which are the output of the wizard, including a grand total of some ten lines of the author's own code. None of this code is commented. None of it is explained properly in the surrounding text. The chapter ends with a few short paragraphs on how to test your ActiveForm. This is not good enough. Is this a book written for Delphi programmers who are new to COM, or is it a book for people who already have a grounding in COM but who are new to Delphi? Mr Harman suggests the former: I would suggest that the latter is actually closer to the mark... A good introduction to COM? Could do (quite a bit) better.
|
With an Amazon.co.uk 
