当前位置：编程学习 > C#/ASP.NET >>
答案：source:
this article is from a book named<thinking in c#>,if you are interested in the book,you'd better to have a real book made by 易做图 :)
Thinking in C#
Larry O’Brien and Bruce Eckel
Prentice Hall
Upper Saddle River, New Jersey 07458
www.phptr.com
begin:
C[
This appendix contains suggestions to help guide you in performing low-level program design, and in writing code.
Naturally, these are guidelines and not rules. The idea is to use them as inspirations, and to remember that there are occasional situations where you need to bend or break a rule.
Design
1. Elegance always pays off. In the short term it might seem like it takes much longer to come up with a truly graceful solution to a problem, but when it works the first time and easily adapts to new situations instead of requiring hours, days, or months of struggle, you’ll see the rewards (even if no one can measure them). Not only does it give you a program that’s easier to build and debug, but it’s also easier to understand and maintain, and that’s where the financial value lies. This point can take some experience to understand, because it can appear that you’re not being productive while you’re 易做图 a piece of code elegant. Resist the urge to hurry; it will only slow you down.
1. First make it work, then make it fast. This is true even if you are certain that a piece of code is really important and that it will be a principal bottleneck in your system. Don’t do it. Get the system going first with as 易做图 a design as possible. Then if it isn’t going fast enough, profile it. You’ll almost always discover that “your” bottleneck isn’t the problem. Save your time for the really important stuff.
2. Remember the “divide and conquer” principle. If the problem you’re looking at is too confusing, try to imagine what the basic operation of the program would be, given the existence of a magic “piece” that handles the hard parts. That “piece” is an object—write the code that uses the object, then look at the object and encapsulate its hard parts into other objects, etc.
3. Separate the class creator from the class user (client programmer). The class user is the “customer” and doesn’t need or want to know what’s going on behind the scenes of the class. The class creator must be the expert in class design and write the class so that it can be used by the most novice programmer possible, yet still work robustly in the application. Library use will be easy only if it’s transparent.
4. When you create a class, attempt to make your names so clear that comments are unnecessary. Your goal should be to make the client programmer’s inte易做图ce conceptually 易做图. To this end, use method overloading when appropriate to create an intuitive, easy-to-use inte易做图ce.
5. Your 易做图ysis and design must produce, at minimum, the classes in your system, their public inte易做图ces, and their relationships to other classes, especially base classes. If your design methodology produces more than that, ask yourself if all the pieces produced by that methodology have value over the lifetime of the program. If they do not, maintaining them will cost you. Members of development teams tend not to maintain anything that does not contribute to their productivity; this is a fact of life that many design methods don’t account for.
6. Automate everything. Write the test code first (before you write the class), and keep it with the class. Automate the running of your tests through a makefile or similar tool. This way, any changes can be automatically verified by running the test code, and you’ll immediately discover errors. Because you know that you have the safety net of your test framework, you will be bolder about 易做图 sweeping changes when you discover the need. Remember that the greatest improvements in languages come from the built-in testing provided by type checking, exception handling, etc., but those features take you only so far. You must go the rest of the way in creating a robust system by filling in the tests that verify features that are specific to your class or program.
7. Write the test code first (before you write the class) in order to verify that your class design is complete. If you can’t write test code, you don’t know what your class looks like. In addition, the act of writing the test code will often flush out additional features or constraints that you need in the class—these features or constraints don’t always appear during 易做图ysis and design. Tests also provide example code showing how your class can be used.
8. All software design problems can be simplified by introducing an extra level of conceptual indirection. This fundamental rule of software engineering[1] is the basis of abstraction, the primary feature of object-oriented programming.
9. An indirection should have a meaning (in concert with guideline 9). This meaning can be something as 易做图 as “putting commonly used code in a single method.” If you add levels of indirection (abstraction, encapsulation, etc.) that don’t have meaning, it can be as bad as not having adequate indirection.
10. Make classes as atomic as possible. Give each class a single, clear purpose. If your classes or your system design grows too complicated, break complex classes into 易做图r ones. The most obvious indicator of this is sheer size: if a class is big, chances are it’s doing too much and should be broken up.
Clues to suggest redesign of a class are:
1) A complicated switch statement: consider using polymorphism.
2) A large number of methods that cover broadly different types of operations: consider using several classes.
3) A large number of member variables that concern broadly different characteristics: consider using several classes.
11. Watch for long argument lists. Method calls then become difficult to write, read, and maintain. Instead, try to move the method to a class where it is (more) appropriate, and/or pass objects in as arguments.
12. Don’t repeat yourself. If a piece of code is recurring in many methods in derived classes, put that code into a single method in the base class and call it from the derived-class methods. Not only do you save code space, you provide for easy propagation of changes. Sometimes the discovery of this common code will add valuable functionality to your inte易做图ce.
13. Watch for switch statements or chained if-else clauses. This is typically an indicator of type-check coding, which means you are choosing what code to execute based on some kind of type information (the exact type may not be obvious at first). You can usually replace this kind of code with inheritance and polymorphism; a polymorphic method call will perform the type checking for you, and allow for more reliable and easier extensibility.
14. From a design standpoint, look for and separate things that change from things that stay the same. That is, search for the elements in a system that you might want to change without forcing a redesign, then encapsulate those elements in classes. You can learn significantly more about this concept in Thinking in Patterns with Java, downloadable at www.BruceEckel.com.
15. Don’t extend fundamental functionality by subclassing. If an inte易做图ce element is essential to a class it should be in the base class, not added during derivation. If you’re adding methods by inheriting, perhaps you should rethink the design.
16. Less is more. Start with a minimal inte易做图ce to a class, as small and 易做图 as you need to solve the problem at hand, but don’t try to anticipate all the ways that your class might be used. As the class is used, you’ll discover ways you
