. Net Situation-driven design (scenario driven design)
In the computing industry where new concepts are rampant, render manager has nothing to do. Don't worry about agile, model-driven, and Ajax every day. However, the stomach will feel unwell after listening to these days. So, I would like to commend scenario driven, an obscure case-driven student, for the design method used by. NET Framework.
Both situation-driven and model-driven are design methods. The difference is that situation-driven focuses more on API usability and functional coordination. We divide developers into three types: Zhang Fei, Guan Yu, And Zhuge Liang. Why not Liu Bei? Because Liu Bei is the manager. Zhang Fei is a very fierce kind. He never reads documents. What is the beauty of the Book of war? Let's talk about it first. Zhang Fei mainly develops vertical applications with a small range of APIS, but must be simple and practical. He does not like reading books or learning in practice. Guan Yu is more practical. He also needs to take a look at the Art of War when playing a big game, but what about wenwushuang's double degree. Guan Yu pays more attention to the balance between functions and development efficiency, wants to develop programs efficiently, and wants to use various advanced functions. Zhuge Liang is familiar with the military book, and then a fan of the world. To design an API for him, you must elaborate on the implementation principles of each part. If others are not satisfied, you must allow others to replace them with their own implementations. In the past, the three heroes had different practices. But now, it is not easy to design a class library for these three heroes at the same time.
In the model-driven method, we open a UML tool, design the object model using the object-oriented method, and then get the salary. In a case-driven method, this is incorrect. We must first write a sample of how users will use these APIs, that is, the situation (scenario ), then, design the API based on these usage. For example, when designing a car, the primary consideration is the feelings of people driving in the car, rather than the horsepower and flexibility. The APIS designed by this method may not comply with the object-oriented (OOP) principle, but it emphasizes not to design APIS by sticking to the object-oriented methods. Because the object-oriented method is invented to design an easy-to-Modify and flexible internal implementation, rather than for external API design.
How can we make Zhang Fei easy to use and give Zhuge Liang enough functions and flexibility. Obviously, the same API cannot be used. The principle used here is "make the routine tasks easy and the advanced tasks possible )". Class methods provide few simple overloading parameters for common method calls, and provide sufficient parameter overloading for advanced functions, such as graphics. drawstring (); in a class, place common classes in the primary namespace, and advanced function classes in the subnamespace, such as system. drawing is a commonly used graphics class, and advanced vector functions are in the system. drawing. in drawing2d, advanced image processing is implemented in system. drawing. imaging.
Zhang Fei's lack of reading documents can be difficult to deal with. In order for him to get started, the API must be self-documenting and support experimentation ). Self-Explanation means that the new API must be similar to what Zhang Fei is familiar. For example, if your API follows this mode, Zhang Fei knows how to use the "Create, set attributes, and call methods" mode of the component. Experiment means that to allow Lao Zhang to find out the correct usage through several guesses and attempts, he must be guided by the name, at the same time, there should be abnormal information indicating how to correct it. For example, there is a printqueue class that provides the print queue interface, but Zhang Fei does not care whether there is a print queue. He just wants to print the document and only wants to use printer.
Zhuge Liang picked up the document, started from the beginning to the end, then came up with a bunch of usage we never thought about, and then wrote 5 minutes of code. If our API gets stuck with someone else, that's my fault. At this time, the classic ideas of functionality, efficiency, flexibility, and scalability are on the paper. Even so, do not forget the oldest principle of programming: small is beautiful. Less code, less bugs.
Zhang Fei and Zhuge Liang have done all the work, but they are afraid that Guan Yu will not be able to do so.
Regardless of the strict definition, the case-driven and Use Case Study in the model-driven systems are similar in that they must be optimized from the perspective of the Use method, however, the use case only takes the final software user into consideration.