home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / object / 4617 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  3.3 KB
  1. Path: sparky!uunet!usc!sdd.hp.com!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!usenet.coe.montana.edu!news.u.washington.edu!ogicse!cadreor!fripp!usenet
  2. From: jc@ri.cadre.com (Joe Cascio)
  3. Newsgroups: comp.object
  4. Subject: Re: OO & transaction handling systems
  5. Message-ID: <1992Dec21.161544.22621@fripp.ri.cadre.com>
  6. Date: 21 Dec 92 16:15:44 GMT
  7. Article-I.D.: fripp.1992Dec21.161544.22621
  8. References: <1194@kps.se>
  9. Sender: usenet@fripp.ri.cadre.com (USENET News Poster Account)
  10. Reply-To: jc@ri.cadre.com
  11. Organization: Cadre Technologies Inc., Providence, RI
  12. Lines: 65
  13. Nntp-Posting-Host: 192.9.200.27
  14.  
  15. I don't have ready answers for all your questions, but
  16. here are some...
  17.  
  18. >Currently we program in C & Oracle on a Pyramid MIS. The thing that 
  19. >attracts me to an object way of doing things is that we have a large 
  20. >number of types of transactions. There are also many types of 
  21. >customers each of which have different functions associated with them. 
  22. >
  23. >'Sounds object-like, doesn't it? 
  24.  
  25. Sure does. Something you might run into is the
  26. "cross-product" problem.  In your case this is
  27. types_of_customers vs. types_of_transaction.  This typcially
  28. results in a large number of possible combinations, not all
  29. of which are unique.  Beware of trying to solve this all with
  30. inheritance!!
  31.  
  32. This particular problem may be better solved with a third set
  33. of classes that treat the combinations of transactions vs.
  34. customers, and use instances of those classes.  Try to keep
  35. any knowledge of customer types out of the transactions, and
  36. vice versa.  Let this third "owner" class worry about the
  37. cross-product.  If you're really compelled to use
  38. inheritance, you could create "mix-ins" with multiple
  39. inheritance that let you combine the attributes of the
  40. appropriate sub-types.
  41.  
  42. >3) Are there any products that can help with storage / access
  43. >   considerations? 
  44. >
  45.  
  46. There are several OO database systems (e.g., Object Design)
  47. available now that map the objects in memory directly to disk
  48. and back, so you don't have to go through the conversion
  49. process.
  50.  
  51. >4) It is said that OO systems don't necessarily have performance problems.
  52. >   Is that true for OO systems as they grow in size? The size and 
  53. >   complexity were exactly why one chooses a relational DB. OO may help 
  54. >   me with the complexity, but can handle the amount of data? Recall 
  55. >   5 years ago relational DB were said to have performance problems in 
  56. >   this regard.
  57. >
  58.  
  59. I can only comment on C++ here.  A well-designed C++
  60. implementation has no inherent performance penalites over C.
  61. The problem is the "well-designed" qualification.  New C++
  62. users are prone to mis-using inheritance and virtual
  63. functions, and ignoring really important aspects, which are
  64. encapsulation, decoupling, and cohesion.  This can cause the
  65. implementation to become overly complex or convoluted, which,
  66. of course, leads to inefficiency.
  67.  
  68.  
  69. ---
  70. ==============================================================
  71. * Joe Cascio                u----wm-
  72. * Cadre Technologies Inc.        /\
  73. * 222 Richmond St.              0_/  "$@@#!$#@$^&"
  74. * Providence, RI 02903 USA       \
  75. * phone: 401-351-5950             |     . .
  76. * FAX  : 401-455-6803            /|   .    .   . .
  77. * email: jc@cadre.com           / | .       . .   . . .
  78.                                ^  ^          .     .   . ....
  79. ==============================================================
  80.