10 JAVA MAXIMS: The Best Ways to Implement Your Design SJTU CLASS

The Best Ways to Implement Your Design Good Java developers write and implement applications swiftly while creating code that is highly logical and reusable. By Bruce Eckel

The Best Ways to Implement Your Design To make your Java code perform as it should—that is, with as few snags as humanly and technically possible—there are certain general rules programmers must follow. These are mostly common-sense solutions, such as using established coding conventions, making sure that the code style is standardized so that a team can best utilize it, and making the code readily available for testing at regular intervals.

The Best Ways to Implement Your Design In the end, your code should be as simple and as accessible (meaning without hidden data) as possible, with the development and milestone ground rules clearly spelled out so that everybody working on the project is on the same page throughout the entire cycle. If you follow these rules closely, your code should require fewer adjustments, test better, and perform at an optimum level.

The Best Ways to Implement Your Design With that in mind, this article contains 10 key maxims for efficiently implementing Java code. Read on... Editor's Note: The tips published here are excerpted from Bruce Eckel's book, "Thinking in Java, Second Edition," (Prentice Hall, 2000). It is the second in a series of articles in which Eckel shares his explicit advice on Java development, design, and implementation.Thinking in Java, Second Edition

1.Elegance always pays off l 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 to update down the line, you'll reap the rewards in saved time and sanity—even if no one else can measure them. Not only will this strategy yield a program that's easier to build and debug, but your applications will also be easier to understand and maintain, and that's where the financial value lies. It protects your company's investment in the original program development, so that even if every programmer on the original development team moves on to other things, new talent can pick up where they left off. This point can take some experience to understand, because it can appear that you're not being hurry; it will only create inefficiencies productive while you're making a piece of code elegant. Resist the urge to.

2.First make it work, then make it fast 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. Get the system going first with as simple a design as possible. Then, if it isn't going fast enough, profile it. You'll almost always discover that the bottleneck you thought you had isn't really the most critical problem. This will let you prioritize application optimization tasks appropriately and thus save your time for the really important stuff.

3.Remember the "divide and conquer" principle 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, and so on. This should ensure that you don't end up with programming redundancies, i.e. writing the same piece of application logic multiple times.

4. Separate the class creator from the class user (client programmer) 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.

5. Name classes intelligently Name classes intelligently When you create a class, attempt to use names that are so clear and self-describing that comments are unnecessary. Your goal should be to make the client programmer's interface conceptually simple. To this end, use method overloading when appropriate to create an intuitive, easy-to-use interface

6. Use bare bones methodology Use bare bones methodology Your analysis and design methodology must account for, at minimum, the classes in your system, their public interfaces, and their relationships to other classes, especially base classes. But anything more than that may be overkill. Ask yourself if all the pieces produced by your 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 directly contribute to their productivity; this is a fact of life for which many design methods don't account.

7.Automate everything 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, ongoing 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 making 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.

8. Write test code early Write test code early 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 analysis and design. Tests also provide example code showing how your class can be used.

9. Get abstract Get abstract All software design problems can be simplified by introducing an extra level of conceptual indirection. This fundamental rule of software engineering is the basis of abstraction, the primary feature of object-oriented programming. Get in the habit of using indirection to solve design problems; this skill will serve you well for many, many years to come.

10. An indirection should have a meaning An indirection should have a meaning In concert with Tip No. 9, giving clear, logical definition to indirections is essential to their value. This meaning can be something as simple 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 at all. Bruce Eckel is a frequent author and lecturer on software development practices and was a founding member of the ANSI/ISO C++ committee. He provides public and private seminars and design consulting in C++ and Java. Reach him at