The Object Primer: The Application Developer's Guide to Object-Orientationby Scott W. Ambler
The Object Primer is the ultimate introductory text on object-oriented (OO) technology. By reading this book, you'll gain a solid understanding of object-oriented concepts and object-oriented analysis techniques. Written by a developer for developers, this book will introduce you to object-oriented design in the context of class modeling. It begins with a description of why developers and their organizations want to take advantage of the object-oriented approach, then moves to issues like CRC cards, use cases, and class modeling. It puts the entire OO development process into perspective, presenting both the serial and iterative development strategies. It includes easy-to-follow notations and provides 'cheat-sheets' references for easy accessibility to commonly used information. It includes a complete glossary of terms.
Read an Excerpt
Excerpt from Chapter 2
...change in a single business rule could affect many programs. For example, say you have four structured programs that access the student data table in a university database. Consequently, you add the attribute "Guardian name" to the table. To support this change, all four structured programs need to be modified to work with the new data. Now say you've developed exactly the same systems using object technology. Instead of coding four different applications to work with the student data, you instead code one single class called "Student," which works with this data that encapsulates (contains) both the functionality and the data appropriate to students. To add "Guardian name" you merely have to modify the definition and source code of the class "Student" in one place, not in four. Clearly, this is easier.
As a second example, you may need to modify your existing system to keep track of university administrators. A university administrator is just like a professor, except that in addition to teaching courses, he or she also schedules them. In a structured application, you would potentially need to add a new data table for administrators and a new program module to handle administrative functions. That is a lot of work. In an 00 system, you would define the class "Administrator," which would inherit from "Professor." Granted, you would still need to write code to schedule courses; however, you would not have to worry about all the data and functionality already defined for professors.
The preceding examples illustrate how easy it is to extend existing 00 applications. First, existing classes are easily changed because both the functionality and data reside in one place. Second; through the use of inheritance, new classes are created that take advantage of the behavior implemented by existing classes. No more reinventing the wheel.
2.1.3 Improved QualityQuality systems are on time, on budget, and meet or exceed the expectations of their users. Improved quality comes from increased participation of users in systems development. As you will see in this book, 00 systems development techniques provide greater opportunity for users to participate in the development process (for example, Chapter 3 presents CRC modeling and use case modeling, techniques where users perform the bulk of requirements definition).
Inheritance The representation of an is a, is like, or is kind of relationship between two classes. Inheritance promotes reuse by enabling a subclass to benefit automatically from all the behavior it inherits from its superclass(es).
2.1.4 Financial BenefitsReusability, extensibility, and improved quality are all technical benefits. While they all sound like good things (and they are), the reason they are important is because they lead to the business benefits of 00. From the point of view of our users (remember them, they are the people who pay the bills), the real benefits are we can build systems better, faster, and cheaper (BFC).
While most 00 books like to concentrate on the technical benefits, the only ones that count are the business benefits, such as BFC. Not only are the BFC benefits applicable to project development, they also apply to production. Systems with high rates of reusability have less code to maintain than systems with low rates of reusability (that's because instead of reusing common code, the same code appears over and over again). The more code, the more effort it takes to maintain it. Furthermore, by definition, a system that is easily extensible is easy to maintain. Finally, a system that meets the needs of its users will receive fewer change requests and fewer support calls than a system that doesn't meet their needs.
It's important to note that the benefits of object orientation are achieved throughout the entire lifecycle. We use inheritance throughout analysis, design, and programming. This means we can reuse our analysis and design efforts, as well as our code. To add new features or to modify existing features in a system, we must first update our analysis and design models, and then modify our code. Therefore, both our models and our code must be extensible a (and they are). An indispensable way to improve the quality of systems effectively is to increase the involvement of users throughout the entire development process. That is exactly what 00 does. Therefore, because the technical benefits are realized throughout the entire development lifecycle, the BFC ones are also realized (remember, the BFC benefits are the direct result of the technical benefits).
2.1.5 Increased Chance of Project SuccessTraditionally, developers have not done a good job at delivering affordable systems in a timely manner that meets the needs of their users. As software professionals, we need to find a way to develop high-quality systems quickly and inexpensively: object orientation is one potential solution. I consider a project successful if it is on time, on budget, and meets the needs of its users. Unfortunately, by this definition, almost every single systems development project has failed. Although, at first glance, my definition may appear harsh, it is actually quite fair. To convince yourself of this, consider the following scenario:
- Scenario You and your spouse have decided to take the plunge and have a house custom-built for your family. You go to a house developer, describe your needs and your budget, and tell him to draw up a plan. At your next meeting, the developer shows you something he calls a prototype, which is a scale model of your house that is made out of cardboard. Because it is not what you want, you tell him about a few changes that need to be made. After a few meetings where you evaluate the prototype and suggest changes, you finally have a house design you like. The developer has architectural plans drawn up and, at the next meeting, gets you to sign off on them. You are not an architect, so you really don't understand the drawings. They seem complicated, though, so you think they must be right. You and the developer finally settle on a price of $200,000 and a moving date of June 14th (it's now March 2).
Time goes by, and every second week you receive a progress report from the developer. Although he keeps telling you everything is going well, you begin to suspect something is wrong. Then, during the last week of May, your worst fears are confirmed-you get a call from the developer: "Gee, it seems we're a little behind schedule. Because of unforeseen complications, we've had to tear down and rebuild a few sections of the house, so it won't be ready until July 30th." You stand there in disbelief-your house is going to be seven weeks late, a time slippage of 50 percent! Where are you going to live? To make things worse, the developer tells you "Oh, by the way, we're also a little over budget. Now that we've actually started building +e house, we have a better idea of what it will really cost: $400,000." As you try not to faint, you realize that $400,000 is double the original estimate. You are not happy about the situation, but you have already invested a lot of money, so you tell the developer to continue.
August 14th rolls around and you are finally able to move into your house (the schedule slipped an additional two weeks). You don't mind as much, because the final bill came in at only $385,000. You walk through the front door, and as you try to turn on the lights, you realize there's no light switch. You turn to the developer and ask him how to turn on the lights. "You wanted lights in your house? You never told me that!" he exclaims. Angrily, you reply "Of course I wanted lights! Hey, where are the wall plugs? Isn't there any electricity in this house?"
"There wasn't any electrical wiring in the architectural plans or in the prototype, didn't you notice?" says the developer. "You signed off on them. This is the house you've paid for, so you better get used to it."
Unbelievably, you shout, "This isn't right! You're incompetent! You'll never work in this town again! Get out of my house!" The developer exits quickly, and begins walking to his truck, saying under his breath "That's the problem with people, they don't know what they want. And then when I can't read their minds, they blame me. Boy are people ever stupid."
The house developer showed his clients drawings (models) that they didn't really understand, but still had to accept anyway. The fundamental problem is the developer didn't have a medium he could use to communicate the design effectively to his clients. What he needed was a model that was simple to understand, but still showed the details necessary to make an educated decision about the design of the house. His prototype was simple, yet lacked the required details, while his architectural plans were too complicated. Just like the house developer, as a system developer, you must have a way to communicate your design to your users in a way they can understand.
The developer then went away and built a house that did not meet the needs of its eventual owners. Had the buyer been more involved with the development of the house, he might have realized the house needed to be wired for electricity. This is a fundamental flaw in the way systems are currently developed using structured techniques. Although we know the chance of project success increases as users become more involved in development, users are typically only involved during analysis and user acceptance testing, but not during design and development. You need to find a way to increase the involvement of your users in the development process (in Chapters 3 and 4, you learn techniques to do just that). ...
Project success. A project is considered a success when it is on time, on budget; and meets the needs of its,
Meet the Author
Scott Ambler is an instance of an OOConsultant for roninIntemational (www ronin-ind.com) based in denverColorado. roninInternational implements objectArchitectureConsulting(), cornponentArchltectureConsultingU, and softwareProcessConsulting() operations. Instances of HumanoidLifeForm can send email messages to him at:email@example.com
Scott Ambler is a very versatile object that will polymorphically change type in order to meet the needs of roninInternational clients. For example, he often becomes an OOMentor, OOArchitect, OODeveloper, or SoftwareProcessMentor object. Scott has been an instance of an OOConsultant since 1991. He used to be a MastersStudent object, having received an instance of an InformationScienceDegree from the university0froronto. As a MastersStudent, Scott Ambler did a lot of work in 00 CASE and instantiated a ThesisPaper object in computersupported co-operative work (an academic alias used to describe groupware). The only message his instance of ThesisPaper responds to is sitOnShelfAndGatherDust, which Scott Ambler finds disappointing but predictable. Scott Ambler has worked at a variety of organizations, including instances of Bank, InsuranceCompany, TelecommunicationsCompany, InternetStartup, ServicesOutsourcer, MilitaryContractor, and Product Distributor.
Objects that have been declared as friends of Scott Ambler often send him the message youTakeThisObjectStuffooFar, to which he responds with the text string "It's nothing compared to how far I take Star Trek." In his spare time he likes to write, having instantiated several books about object technology. He also writes regular object columns for softwareDevelopment (www. sdmagazine.com) and computingCanada (wwwplesmanxom). Scott Ambler is an avid watcher of instances of StarTrek, and intends to one day do his doctorateDegree at starFleetAcademy. His personal web site is http-//www. ambysoft.com, where he has posted a collection of WhitePaper objects and other software development resources.
and post it to your social network
Most Helpful Customer Reviews
See all customer reviews >