home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / object / 4674 < prev    next >
Encoding:
Internet Message Format  |  1992-12-30  |  11.3 KB
  1. Path: sparky!uunet!nwnexus!ole!rwing!fnx!sgihbtn!dgeary
  2. From: dgeary@sierra.com (David Geary)
  3. Newsgroups: comp.object
  4. Subject: Re: Need basic OO information
  5. Message-ID: <1992Dec29.161034.13738@sierra.com>
  6. Date: 29 Dec 92 16:10:34 GMT
  7. References: <1992Dec11.125457.36573@uservx.plk.af.mil>
  8. Sender: news@sierra.com
  9. Organization: Sierra Geophysics,  Kirkland WA
  10. Lines: 263
  11. Nntp-Posting-Host: grumpy
  12.  
  13. In article <1992Dec11.125457.36573@uservx.plk.af.mil> tollefson@uservx.plk.af.mil writes:
  14. >Hi,
  15. >
  16. >     I was away from programming (doing management, yuk) during the time
  17. >when object-oriented programming became popular.  Now, as I move closer
  18. >to programming again, I need to quickly gain an understanding of what
  19. >object-oriented programming really has to offer.
  20. >
  21. >     I'm looking for a good book (or E-mail replies) which can help me to
  22. >understand some basics:
  23. >
  24. >      1)  What are the basic benefits?  (why use it over traditional)
  25.  
  26.   When done correctly, OO makes the following *much* easier:
  27.  
  28.   1.  Maintenance.
  29.   2.  Extensibility.
  30.   3.  Ability to change.
  31.  
  32.  
  33. >      2)  How does it work, very generally.  
  34.  
  35.   *Very* generally, classes of objects which exhibit similar behavior are 
  36. developed in a hierarchy of classes.  Using inheritance, specialized classes
  37. are derived from existing, more generalized, classes.  This is a very natural
  38. paradigm for us humans; grouping similar classes of objects in hierarchies
  39. is something we do constantly in everyday life.
  40.  
  41. >          (the only examples I've seen
  42. >          have been complex theoretical nightmares or simple contrived
  43. >          situations easily handled by conventional code.)
  44.  
  45.   The benefits of using OO are proportional to the complexity of the software
  46. being developed.  Therefore, it is difficult to showcase the benefits of OO
  47. without dicussing "complex theoretical nightmares".  Many authors instead
  48. resort to "simple contrived situations", which are of course, "easily
  49. handled by conventional code".
  50.  
  51.  
  52. >      3)  How do you tell when to use it and when to avoid it for
  53. >          specific programs?
  54.  
  55.   OO is applicable across many different types of applications.  There is
  56. some performance penalty for using OO in some situations; for speed critical
  57. apps this may be a problem.
  58.   
  59. >      4)  Can old dogs learn new tricks?  (how hard is it for a programmer
  60. >          to convert his thinking)
  61. >
  62.  
  63.   I think it's a pretty natural thing to pick up.  Unfortunately, a
  64. developer who is mired down in a procedural paradigm may have a harder time
  65. making the switch to OO than someone who has never written a line of code
  66. in their life.
  67.  
  68.   I would recommend getting Smalltalk.  Smalltalk is a pure OO language where
  69. one can really see the benefits of having an existing hierarchy of very
  70. useful classes for building complex applications in a short period of time.
  71.  
  72. >     A description of a case where the programming became much easier or
  73. >the end product became much better would be very helpful.  I'm not looking
  74. >for source code, but some textual information on how the new scheme helped.
  75. >
  76.  
  77.   There are quite a few good books that cover simplistic case studies.  See
  78. the reading list that follows:
  79.  
  80.  
  81. --------------------------------------------------------------------------------
  82.                    Object-Oriented Analysis/Design:
  83. --------------------------------------------------------------------------------
  84.  
  85. Object-Oriented Modeling And Design, Rumbaugh, et al.
  86. -----------------------------------
  87.  
  88.   Intended Audience:  OOP practitioners.
  89.   -----------------   
  90.  
  91.   Excellent writing and presentation get mixed in with some pretty
  92.   intense diagraming techniques for representing class hierarchies, and
  93.   dynamic system behavior.  Many good ideas on how to approach OOA/OOD;
  94.   however, symbology is somewhat complex.  This book also presents the
  95.   OMT (Object Modeling Technique) notation, which is the basis of
  96.   for some modeling tools.
  97.  
  98.  
  99. Object-Oriented Design With Applications, Grady Booch.
  100. ----------------------------------------
  101.  
  102.   Intended Audience:  OOP practitioners.
  103.   -----------------   
  104.  
  105.   Booch, like Budd, presents applications in different languages:  C++, 
  106.   SmallTalk, CLOS, Object Pascal and Ada.  Booch's diagraming techniques
  107.   seem more intuitive than Rumbaugh's.  Booch works at Rational which, among 
  108.   others, provides tools for designing in the Booch notation.
  109.  
  110.  
  111. --------------------------------------------------------------------------------
  112.                       Object-Oriented Programming:
  113. --------------------------------------------------------------------------------
  114.  
  115. Object-Oriented Software Construction, Bertrand Meyer
  116. --------------------------------------
  117.  
  118.   Intended Audience:  Anyone interested in OOP.
  119.   -----------------   
  120.  
  121.   Written by the father of the Eiffel programming language, this book is
  122.   (obviously) biased towards Eiffel and the methodologies it imposes; however
  123.   it is an excellent work on the construction of Object-Oriented software
  124.   in any language.  Meyer also discusses a few things which I have not seen 
  125.   addressed (to the same degree) by other OOP authors, such as assertions
  126.   and programming by contract.  This is a true classic.
  127.  
  128.  
  129. Object-Oriented Programming An Evolutionary Approach, Brad Cox
  130. ----------------------------------------------------
  131.  
  132.   Intended Audience:  OOP developers and OOP managers. 
  133.   -----------------   
  134.  
  135.   Written by the father of Objective-C, this book is also biased towards
  136.   Objective-C, but Brad explores many different areas of OOP and reusability
  137.   other than the usage of programming languages to implement OOP methodologies.
  138.  
  139.   Brad stresses software reuse as an end, to which a programming language
  140.   is (secondarily) a means, which is really the inverse of what Meyer does.
  141.  
  142.   This book gives a realistic viewpoint of where the software development
  143.   industry is today, and where it may be tomorrow.  There is a very interesting
  144.   analogy of the industrial revolution (and the events leading up to it),
  145.   and the inevitable "evolution" of the software industry.
  146.  
  147.  
  148. An Introduction To Object-Oriented Programming, Timothy Budd
  149. ----------------------------------------------
  150.  
  151.   Intended Audience:  OOP practitioners.
  152.   -----------------   
  153.  
  154.   This one is my favorite.  Examples are done in 4 different languages:  
  155.   C++, Objective-C, SmallTalk, and Object Pascal.
  156.  
  157.   Budd is an entertaining writer, and explores many aspects of OOP that
  158.   are lost when an author sticks to one programming language.  He also
  159.   advocates a very simplistic method of OO design, which may be much more
  160.   palletable than the books listed below by Rumbaugh and Booch concerning
  161.   OOA/OOD.
  162.  
  163.  
  164. Software Components In Ada, Grady Booch.
  165. --------------------------
  166.  
  167.   Intended Audience:  Ada programmers, and software engineers in general.
  168.   -----------------   
  169.  
  170.   Obviously slanted towards Ada, Booch nonetheless presents many excellent
  171.   ideas that can be mapped to any programming language.  The design/coding
  172.   of classes one would normally expect to find in a class library, such
  173.   as container classes is explored.  It is enlightening to see how
  174.   many of the advantages of OOP are exploited without the use of
  175.   inheritance.
  176.  
  177.  
  178. Object-Oriented Programming With the X Window System Tookits, Jerry Smith
  179. ------------------------------------------------------------
  180.  
  181.   Intended Audience:  X Window developers.
  182.   -----------------   
  183.  
  184.   This (thick) book provides an interesting look at the "object-oriented" 
  185. implementation of the X Window system in C.  Although I disagree with
  186. some of Jerry's statements concerning what is/is not OOP, and whether the X
  187. Window's OOP technique is on par with C++, nonetheless, exploring the 
  188. implemention of OOP in a non-OOP language is worthwhile in and of itself. 
  189. This book also provides a pragmatic view of developing X apps, and is one
  190. of the better references for "subclassing" X Widgets (not for the faint
  191. of heart!).
  192.  
  193.  
  194. --------------------------------------------------------------------------------
  195.                                   C++:
  196. --------------------------------------------------------------------------------
  197.  
  198. C++ Primer, Stanley Lippman
  199. ----------
  200.  
  201.   Intended Audience:  Beginning and intermediate C++ programmers as a text.
  202.   -----------------   Useful to all C++ programmers as a reference.
  203.  
  204.   Probably the best introduction to C++.  Contains information hard to find
  205.   elsewhere (such as ifstreams and ofstreams).  Now out in a 2nd edition,
  206.   Lippman covers topics ranging from: C++ data types, and naming of variables
  207.   to templates, exception handling, and object-oriented design.
  208.  
  209.  
  210. Effective C++, Scott Meyers
  211. -------------
  212.  
  213.   Intended Audience:  Intermediate C++ programmers.  Much of what Scott
  214.   -----------------   discusses will make a lot more sense if you've actually
  215.               been writing C++ code for a while.
  216.  
  217.   An excellent set of (50) specific methodologies/constructs which one 
  218.   can use to write "effective" C++.  This book will keep you out of 
  219.   trouble, and make your C++ life much easier.  Buy it.
  220.  
  221.  
  222. C++ Programming Style, Tom Cargill
  223. ---------------------
  224.  
  225.   Intended Audience:  Intermediate C++ programmers.  Intended audience is 
  226.   -----------------   much the same as "Effective C++".
  227.   
  228.   Looks like Addison-Wesley (publisher) wanted this book to be viewed as
  229.   a sequel to "Effective C++" (the covers are very similar).  Whereas
  230.   Scott Meyers presents 50 techniques for improving C++ programs, 
  231.   most of which are reinforced by a small code fragment, Cargill presents
  232.   case studies of existing C++ code, and then proceeds to point out flaws in 
  233.   the design/code, and ways to implement the functionality better.  While 
  234.   "Effective C++" presents many small rules to follow, such as:  
  235.   "Have operator= return a reference to *this", "C++ Programming Style"
  236.   covers broader issues, such as:  Abstraction, and the mis-use of Inheritance.
  237.  
  238.  
  239. The Annotated Reference Manual, Bjarne Stroustrup
  240. ------------------------------
  241.  
  242.   Intended Audience:  C++ experts/language-lawyers/compiler writers.  Good
  243.   -----------------   reference for all C++ programmers.
  244.  
  245.   The "ARM" is for heavyweights.  In addition to being a reference for compiler
  246.   writers (it's the ANSI base document), Bjarne waxes eloquent about
  247.   many of the nuances of C++, and the rationale behind them (where
  248.   the "annotated" comes from).
  249.  
  250.   What I especially like is you get to see how certain constructs, such
  251.   as multiple inheritance may be implemented by your compiler.  While it is 
  252.   not essential to know this information to use C++, reading the ARM 
  253.   will improve your debugging skills in C++ by an order of magnitude,
  254.   and give you a deeper understanding of why certain features have/have not
  255.   been included in the language.
  256.  
  257.  
  258. Advanced C++, Programming Styles and Idioms, Coplien
  259. -------------------------------------------
  260.  
  261.   Intended Audience:  Intermediate to expert C++ programmers. 
  262.   -----------------  
  263.  
  264.    This book covers a lot of ground.  From canonical forms for certain
  265.    categories of C++ classes (such as: orthodox, inheritance, etc.)
  266.    to OOD (Coplien espouses Booch's notation) to envelope and letter
  267.    classes, Coplien explores many implementation techniques not
  268.    found in other literature.  Coplien addresses many of the issues Scott
  269.    Meyers talks about, and in addition, presents many idioms to use
  270.    in certain circumstances.  Coplien assumes you are a fluent C++
  271.    programmer who understands OOP. 
  272. -- 
  273. David Geary               |   Seattle - America's most attractive city ... 
  274. Sierra Geophysics    |    
  275. dgeary@sierra.com    |   to the jetstream ;-(
  276.