【導(dǎo)讀】面向?qū)ο笫且环N全新的編程思考方式。第一次了解如何處理一個(gè)OOP工程時(shí)，多數(shù)人都會感到困難。帶來的所有優(yōu)勢，創(chuàng)造出“好”的設(shè)計(jì)了。本章將介紹分析與設(shè)計(jì)的思想，以及一些。方法，以幫助你在適度的時(shí)間內(nèi)開發(fā)出良好的面向?qū)ο蟮某绦?。問題復(fù)雜性的過程與啟發(fā)。自從面向?qū)ο缶幊堂媸酪詠?，已?jīng)系統(tǒng)地提出了許多種。本節(jié)將讓你體會在采用某種方法論時(shí)你將能夠達(dá)到的目標(biāo)。方法論是由許多經(jīng)驗(yàn)積累而成的，特別是在OOP中尤為如此。種方法論之前，弄清楚它能解決什么問題就顯得十分重要。正確，Java是用來降低程序表達(dá)時(shí)的復(fù)雜度的編程語言。了對復(fù)雜的方法論的需求程度。論就足以解決大多數(shù)問題。有效，那么只需要對它作小小的調(diào)整，就能將它應(yīng)用于Java。種形式化的方法論中選擇多個(gè)部分加以應(yīng)用。但是請記住，多數(shù)工程并屬于這一范疇，采用某種比直接開始編碼要好得多的方式。法確定當(dāng)前階段的每一個(gè)細(xì)節(jié)。的很好的解法，因此對它們的研究就很有必要。

　　

【正文】 . Or a manager might have already decided how long the project should take and will try to influence your estimate. But it’s best to have an honest schedule from the beginning and deal with the tough decisions early. There have been a lot of attempts to e up with accurate scheduling techniques (much like techniques to predict the stock market), but probably the best approach is to rely on your experience and intuition. Get a gut feeling for how long it will really take, then double that and add 10 percent. Your gut feeling is probably correct。 you can get something working in that time. The “doubling” will turn that into something decent, and the 10 percent will deal with the final polishing and you want to explain it, and 英文翻譯 原文 第 17 頁 (共 21 頁 ) regardless of the moans and manipulations that happen when you reveal such a schedule, it just seems to work out that way. Phase 2: How will we build it? In this phase you must e up with a design that describes what the classes look like and how they will interact. An excellent technique in determining classes and interactions is the ClassResponsibilityCollaboration (CRC) card. Part of the value of this tool is that it’s so lowtech: You start out with a set of blank 3 x 5 cards, and you write on them. Each card represents a single class, and on the card you write: The name of the class. It’s important that this name capture the essence of what the class does, so that it makes sense at a glance. The “responsibilities” of the class: what it should do. This can typically be summarized by just stating the names of the methods (since those names should be descriptive in a good design), but it does not preclude other notes. If you need to seed the process, look at the problem from a lazy programmer’s standpoint: What objects would you like to magically appear to solve your problem? The “collaborations” of the class: What other classes does it interact with? “Interact” is an intentionally broad term。 it could mean aggregation or simpl y that some other object exists that will perform services for an object of the class. Collaborations should also consider the audience for this class. For example, if you create a class Firecracker, who is going to observe it, a Chemist or a Spectator? The former will want to know what chemicals go into the construction, and the latter will respond to the colors and shapes released when it explodes. You may feel that the cards should be bigger because of all the information you’d like to get on them. However, they are intentionally small, not only to keep your classes small but also to keep you from getting into too much detail too early. If you can’t fit all you need to know about a class on a small card, then the class is too plex (either you’re getting too detailed, or you should create more than one class). The ideal class should be understood at a glance. The idea of CRC cards is to assist you in ing up with a first cut of the design so that you can get the big picture and then refine your design. 英文翻譯 原文 第 18 頁 (共 21 頁 ) One of the great benefits of CRC cards is in munication. It’s best done in real time, in a group, without puters. Each person takes responsibility for several classes (which at first have no names or other information). You run a live simulation by solving one scenario at a time, deciding which messages are sent to the various objects to satisfy each scenario. As you go through this process, you discover the classes that you need along with their responsibilities and collaborations, and you fill out the cards as you do this. When you’ve moved through all the use cases, you should have a fairly plete first cut of your design. Before I began using CRC cards, the most successful consulting experiences I had when ing up with an initial design involved standing in front of a team—who hadn’t built an OOP project before—and drawing objects on a whiteboard. We talked about how the objects should municate with each other, and erased some of them and replaced them with other objects. Effectively, I was managing all the “CRC cards” on the whiteboard. The team (who knew what the project was supposed to do) actually created the design。 they “owned” the design rather than having it given to them. All I was doing was guiding the process by asking the right questions, trying out the assumptions, and taking the feedback from the team to modify those assumptions. The true beauty of the process was that the team learned how to do objectoriented design not by reviewing abstract examples, but by working on the one design that was most interesting to them at that moment: theirs. Once you’ve e up with a set of CRC cards, you may want to create a more formal description of your design using don’t need to use UML, but it can be helpful, especially if you want to put up a diagram on the wall for everyone to ponder, which is a good idea (there is a plethora of UML diagramming tools available). An alternative to UML is a textual description of the objects and their interfaces, or, depending on your programming language, the code itself. UML also provides an additional diagramming notation for describing the dynamic model of your system. This is helpful in situations in which the state transitions of a system or subsystem are dominant enough that they need their own diagrams (such as in a control 英文翻譯 原文 第 19 頁 (共 21 頁 ) system). You may also need to describe the data structures, for systems or subsystems in which data is a dominant factor (such as a database). You’ll know you’re done with Phase 2 when you have described the objects and their interfaces. Well, most of them—there are usually a few that slip through the cracks and don’t make themselves known until Phase 3. But that’s OK. What’s important is that you eventually discover all of you