************************************* * * * DB/C Newsletter * * January 1998 * * * ************************************* News and Comments This is the first DB/C Newsletter in several months. There are three reasons for the interruption: first, we've been spending all of our time working on the DB/C JX and DB/C FS; second, there hasn't been much other news of interest; and third, it took some time to convert away from majordomo to MS Exchange for the email distribution of the newsletter. With regard to DB/C JX and DB/C FS: these new products are now in beta testing. We expect to release them in several weeks. If you are interested in participating in the beta test program for either or both products, send me an email. We are now working on the next release of traditional DB/C which will be called DB/C DX Release 10. We have not made final decisions about new features, so if there is a feature that you would like us to consider adding, please let us know. We expect to begin testing DB/C DX sometime in the 2nd quarter of this year. Production should follow soon thereafter. The UK DATABUS User's Group will hold its annual meeting on March 18, 1998 in Birmingham, England. I will be attending (in person, not virtually like last year) to present a detailed description of DB/C JX and DB/C FS. If you are interested, contact Frank Valvano at frank.valvano@cmssoft.co.uk. As we have stated earlier, Java is a major part of the future of DB/C. Several customers have asked how to get started with Java. The answer is to read books and experiment with software. There are two sets of books we recommend. The first set is the Addison-Wesley set called The Java Series. The second is the O'Reilly set also called The Java Series. Information about these two sets of books can be found at: http://www.awl.com/cseng/javaseries/index.html http://www.oreilly.com/publishing/java/ There is plenty of great Java development software. Most operating system vendors provide a free development kit including a command-line Java compiler and a Java virtual machine. Many other vendors provide robust Java Integrated Development Environments (IDEs). Here are some of the many URLs that are useful for finding free Java software and technical documentation: http://java.sun.com http://www.ibm.com/java http://www.microsoft.com/java http://applejava.apple.com http://www.novell.com/java We have tentatively scheduled the three day DB/C Fundamentals Class for the last week in February. It will be held in our Oak Brook offices. For more information contact Judi Tamkevic by email at dbc@swc.com or by phone at 630.572.0240. This month's article is about design patterns. I hope you find it interesting and useful. don.wills@swc.com ******************************************************************************* Design Patterns by Don Wills As I was reading the first chapter of the book "Developing Java Beans" by Robert Englander (published by O'Reilly & Associates), I came across the term "design patterns" to describe how various Java Beans methods are named. The author notes "This term [design patterns] is commonly used to describe the practice of documenting a reusable design in object-oriented software." This started me thinking about just what design patterns I have ever used or even known of. I have used many algorithms over the years, but I couldn't really think of any design patterns, so I immediately went out and purchased the bible of design patterns - "Design Patterns Elements of Reusable Object-Oriented Software" by Erich Gamma and others (published by Addison-Wesley). I had previously dismissed Gamma's book as just another ivory tower treatise on system analysis and design, probably because Grady Booch's name was highlighted on the cover as the author of the Foreword. I have never been a fan of structured design, object-oriented design, CASE tools, etc. In my opinion, Grady Booch and Ed Yourdon are the cause of billions of dollars of waste - money wasted on huge paper designs that have very little connection with reality and that have only occasionally been programmed into successfully running systems. So I read Gamma's "Design Patterns" and was pleasantly surprised. This book is a great description of the problems and solutions that happen during the creation of a system that is being written with an object-oriented programming language. It describes 23 different general purpose program design patterns. To my amazement, I recognized several patterns that I have used. What's also interesting is that the author gives names to the patterns, so that in the future I can think - I'll use the Facade pattern, or I'll use the Composite pattern. The Gamma book is not useful as an introduction to object-oriented (OO) programming. If you are not very familiar with an object-oriented programming language, I recommend you become so before reading Gamma's book. There are many good books that introduce OO programming (e.g. the books by Bertrand Meyer, the father of OO programming languages). My experience in this area is that to really understand the concepts of OO programming, you have to actually write one or more real systems using real OO programming techniques. As a programmer who learned the trade before OO programming existed, I know it is very hard to adjust to the way OO systems are written. Unfortunately, DB/C and C++ are not helpful because they both let you do it either way - OO or non-OO. When given the option, old-timers like me tend to fall back to the non-OO way of writing a program or a section of code. Anyway, after reading both of these books, I came to the realization that almost everything a programmer does while writing a program is part of a pattern. A program consists of small, medium and large patterns. A small pattern might be just the naming of local index variables with the same names (e.g. I, J, N1, N2, etc.). An example of a large pattern is the way Dave Subject (the S of SWC) has always written customized printed reports. Dave found it easiest to model DB/C report programs after RPG, going as far as naming the variables by their break level and putting before and after routines at certain places in the program. I never did quite understand this design pattern because I never learned RPG. But for Dave it made creation and maintenance of report programs much faster and less error prone. Experienced programmers reuse many different design patterns all the time, whether they realize it or not. Inexperienced programmers don't have knowledge of these patterns, and therefore they have to invent their own patterns as they write a program. This is one plausible reason that really good programmers can be as much as 100 times more productive than inexperienced programmers. Programming is an art, not a science. The utility of describing, writing about, and talking about design patterns, both small and large, is to make it easier for an inexperienced programmer to become proficient at the art of writing good programs. Design patterns should become part of the everyday vocabulary of each and every computer programmer. So the next time you write a program, think about the steps you go through as you write the program. And try to write down the exact patterns that you use as you actually write each line and section of the program. I bet you'll recognize that you're just doing something that you've done before, maybe a little differently this time, but definitely the same pattern that you've used before. Then communicate these patterns to the other programmers you work with. I'm sure it will make for an interesting and constructive conversation. ******************************************************************************* Subscribing to the DB/C Newsletter If you don't already have the DB/C Newsletter delivered to your email address and would like to have it emailed to you when it is produced, just send an email message to 'request@swc.com' and put the line 'subscribe dbcnews' in the body of the email message (omit the ' characters). The newsletter will be delivered to the email address from which the message was sent. To stop delivery, put the line 'unsubscribe dbcnews' in the body of the message.