CodeGuru Staff

Bruce Eckel’s Thinking in Java Contents | Prev | Next Various designs in this chapter attempt to remove RTTI, which might give you the impression that it’s “considered harmful” (the condemnation used for poor, ill-fated goto, which was thus never put into Java). This isn’t true; it is the misuse of RTTI that is the […]

Bruce Eckel’s Thinking in Java Contents | Prev | Next Now consider applying a design pattern with an entirely different goal to the trash-sorting problem. For this pattern, we are no longer concerned with optimizing the addition of new types of Trash to the system. Indeed, this pattern makes adding a new type of Trash […]

Bruce Eckel’s Thinking in Java Contents | Prev | Next The above design is certainly satisfactory. Adding new types to the system consists of adding or modifying distinct classes without causing code changes to be propagated throughout the system. In addition, RTTI is not “misused” as it was in RecycleA.java. However, it’s possible to go […]

Bruce Eckel’s Thinking in Java Contents | Prev | Next With creation out of the way, it’s time to tackle the remainder of the design: where the classes are used. Since it’s the act of sorting into bins that’s particularly ugly and exposed, why not take that process and hide it inside a class? This […]

Bruce Eckel’s Thinking in Java Contents | Prev | Next The solutions in Design Patterns are organized around the question “What will change as this program evolves?” This is usually the most important question that you can ask about any design. If you can build your system around the answer, the results will be two-pronged: […]

Bruce Eckel’s Thinking in Java Contents | Prev | Next The nature of this problem is that the trash is thrown unclassified into a single bin, so the specific type information is lost. But later, the specific type information must be recovered to properly sort the trash. In the initial solution, RTTI (described in Chapter […]

Bruce Eckel’s Thinking in Java Contents | Prev | Next The observer pattern solves a fairly common problem: What if a group of objects needs to update themselves when some object changes state? This can be seen in the “model-view” aspect of Smalltalk’s MVC (model-view-controller), or the almost-equivalent “Document-View Architecture.” Suppose that you have some […]

Bruce Eckel’s Thinking in Java Contents | Prev | Next Initially, you can think of a pattern as an especially clever and insightful way of solving a particular class of problems. That is, it looks like a lot of people have worked out all the angles of a problem and have come up with the […]

Bruce Eckel’s Thinking in Java Contents | Prev | Next This chapter introduces the important and yet non-traditional “patterns” approach to program design. Probably the most important step forward in object-oriented design is the “design patterns” movement, chronicled in Design Patterns , by Gamma, Helm, Johnson & Vlissides (Addison-Wesley 1995). [70] That book shows 23 […]

Bruce Eckel’s Thinking in Java Contents | Prev | Next Traditional approaches to executing code on other machines across a network have been confusing as well as tedious and error-prone to implement. The nicest way to think about this problem is that some object happens to live on another machine, and you can send a […]

Bruce Eckel’s Thinking in Java Contents | Prev | Next with JDBC It has been estimated that half of all software development involves client/server operations. A great promise of Java has been the ability to build platform-independent client/server database applications. In Java 1.1 this has come to fruition with Java DataBase Connectivity (JDBC). One of […]

Bruce Eckel’s Thinking in Java Contents | Prev | Next A Java program can send a CGI request to a server just like an HTML page can. As with HTML pages, this request can be either a GET or a POST. In addition, the Java program can intercept the output of the CGI program, so […]