home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / object / 4516 < prev    next >
Encoding:
Text File  |  1992-12-12  |  3.0 KB  |  57 lines
  1. Newsgroups: comp.object
  2. Path: sparky!uunet!psinntp!afs!greg
  3. From: greg@afs.com (Gregory H. Anderson)
  4. Subject: Re: Really Object-Oriented?
  5. Message-ID: <1992Dec11.165212.1671@afs.com>
  6. Sender: greg@afs.com
  7. Reply-To: greg@afs.com
  8. References: <142936@lll-winken.LLNL.GOV>
  9. Date: Fri, 11 Dec 1992 16:52:12 GMT
  10. Lines: 45
  11.  
  12. In article <142936@lll-winken.LLNL.GOV> jeh@windrider.llnl.gov (Jose E.  
  13. Hernandez) writes:
  14. > Some software packages are internally implemented using object-oriented
  15. > languages.  From an users view point the key thing is wether the
  16. > paradigm is available to the end user too. I am talking about the
  17. > ability to customize the behaviour of the package by allowing the end
  18. > user to define more specialized representations through inheretance.  To
  19. > me this would be the minimum requirement to think of a software package
  20. > as object-oriented.
  21. > 
  22. I agree, and as a third-party NeXT developer, that is the only way we are  
  23. developing software anymore. We have a customizable Wall Street trading  
  24. application that is basically a kit (library) of objects and nib files (if  
  25. you are unfamiliar with NeXT, nib files are archives of the UI objects  
  26. that get reloaded and reinstantiated at runtime) that *just*so*happen* to  
  27. compile into a serviceable "shrink-wrapped" app in their native state. But  
  28. you can subclass them and build a customer-specific version with very  
  29. little knowledge of how actual Wall Street trading works.
  30.  
  31. Here's another terrific example. Early next year, we will be releasing a  
  32. project management/time billing system and an accounting system built  
  33. along the same lines. End-users can buy a shrink-wrapped package from us,  
  34. which is a simple compilation of the standard AfsAccountingKit, or they  
  35. can buy the kit and customize at their discretion. Since NeXT allows  
  36. delegation and runtime linking/loading, we are taking advantage of those  
  37. capabilities to let users specify on the Preferences Panel which CLASS  
  38. they want to use for certain operations. 
  39.  
  40. For example, the project management system will (obviously) perform  
  41. graphing of time lines. The graphing classes will have a protocol, similar  
  42. to you might publish as an external API. As long as they observe the  
  43. protocol, users will be able to write (or have someone else write) their  
  44. own graphing objects and then tell the system at runtime, through a  
  45. Preferences selection, to use them instead of the standard class. THIS IS  
  46. COOL STUFF! THIS IS SERVING THE USERS! THIS IS WHY OBJECT-ORIENTED  
  47. PROGRAMMING IS SUPERIOR TO TRADITIONAL METHODS! There is no other way of  
  48. programming that gives users this much control without buying source. Plus  
  49. internalizing the API is inherently faster and more controlled. In my  
  50. view, this is a very big win.
  51.  
  52. --
  53. Gregory H. Anderson          | Thus spake the master programmer: 
  54. Master Programmer / Manager  | "Let the programmers be many and  
  55. Anderson Financial Systems   | the managers few; then all will be 
  56. greg@afs.com  (Nextmail OK)  | productive." -- Tao of Programming
  57.