Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Java Books Media Programming Book Reviews

Applied Java Patterns 114

David Kennedy writes "Applied Java Patterns is an adequate Design Patterns reference for those who must have a Java version of the classic Gamma et al (aka Gang of Four, or GoF) Design Patterns, but it's only adequate. If C++ or Smalltalk hold little fear for you, stick with the original sources: 'This isn't the definitive Java Design Patterns book we're looking for -- move along.'" Read on for the rest of David's review.
Applied Java Patterns
author Stephen Stelting and Olav Maassen
pages 561
publisher The Sun Microsystems Press / Prentice Hall
rating B
reviewer David Kennedy
ISBN 0130935387
summary Adequate Java implementation of "Design Patterns"

Check your sources.

The title is published by Sun Microsystems Press, and the two authors are instructors for Sun Microsystems. As you would expect, this means you won't find any discussion of Java's darker corners; this isn't a particularly damning criticism in a book about Design Patterns, but it does mean that, for example, you won't see discussion on why double-checked locking implementations of the Singleton pattern don't work. (I might be reading more authorial/editorial bias into this than was intended of course -- I'm a bit paranoid. Too much caffeine, I expect.)

What's the book about?

From the blurb:

"[...] After briefly reviewing the fundamentals of design patterns, the authors describe how they can be applied effectively to the Java platform and present proven techniques for all types of patterns, from system architecture to single classes. Next, they present a pattern catalog."

In other words, what we get is an adequate intro, followed by about 275 pages of pattern catalog (mostly from Gamma et al, with a few threaded items from Doug Lea's Concurrent Programming in Java). This is what you're buying the book for, and on the whole it's decent material.

It continues:

"In addition, they identify patterns in the core Java APIs and present techniques for pattern use in distributed development. [this title] also features a section on pattern use in systems built with J2EE and Jini technology and coverage of the servlet, JSP, and EJB APIs."

Just about! This entire section is very much secondary to the catalog. The core Java APIs discussion is about 20 pages, the distributed section about a dozen, and the rest only 15! I've seen as much discussion of the pattern usage in the JDK in asides in, for example, Bloch's Effective Java (an excellent book by the way).

Of much more interest are the appendices. In reverse order -- Appendix B is a welcome bibliography. Appendix A is an odd decision on the part of the publisher. Appendix A is "Full Code Examples." Normally I'd think that this is a good thing, but appendix A is 224 pages, as compared to 273 for the whole pattern catalog. I feel it would have been better delivered on a CD. I realise this adds, what? $5?, to the cover cost, but the book would have been substantially thinner, with a knock-on effect on price.

A more important consideration is that this appendix distracts from the catalog, and adds little (other than working framing code) to the discussion of the patterns.

Target audience?

Experienced Java developers - but ones who haven't been exposed to Design Patterns before. I doubted that this was a huge audience, but then realised that Java is often used as a teaching language now, and I may be wrong in assuming most graduate programmers would be comfortable with the C++ and Smalltalk examples in Gamma et al. I could see this being a useful niche title for those mono-linguists starting out their professional careers.

What's good?

Overall, this isn't a bad title. It's decently written on the whole, has passable explanations of the main Patterns, and is presented clearly. It's just that there's nothing superb about it, and the problems (below) offset the overall competent tone. (It's a weird book to review: the majority of the content isn't original, and as a repackaging exercise I can't comment on, say, how brilliant it is to have a name of the Factory concept at long last.)

What's bad?

Too much for a simple port of GoF to Java. Let's start with the obvious flaws and then move onto "missed opportunities":

  • Diagrams
    Sorry, but there is no way that the UML diagrams in this title are acceptable in a professional publication. They're woeful, jagged-edged screen-capture affairs.

  • Appendix A
    As discussed above, the book has a schizophrenic feel with a LOT of material relegated to, or repeated in, Appendix A. A much more useful approach would have been to provide more material on the applicability of each pattern, or to flesh out some of the alternative implementations discussed.

  • The example application
    This title tries to do something laudable, but ill-thought out. What they do is start to discuss an example application (the Personal Information Manager) in the first pattern, and then carry that example through to all the other examples. This isn't a bad idea, but think about it. How do you use your pattern books? I flick through mine. I pull it off the shelf and read one pattern, or pass it to a colleague saying, "You want to change that to a [whatever]."

    When reading this title my flatmate was struggling with some OO design homework -- flicking to the pattern under discussion (Composite) starts us into another discussion of the PIM! This isn't what I want and puts me off the title immediately as I feel like I'm missing some background. The examples need to be more standalone. (To be fair, this only affects the blurb text, the code is independent.)

  • Oh editor, where art thou?
    While talking over the Composite pattern with my confused flat-mate, I noted that the Deliverable snippet actually gives the code for the ProjectItem again (page 163). Sadly, it's also wrong in Appendix A. On the full read-through this type of simple proof-reading error occurred too often.

  • Oh code reviewer, where art thou?
    Here's a hint for publishers. When writing a book for a professional audience which necessarily thrives on pedantry, try and have examples peer-reviewed first. Much of the code in Appendix A is not great. Now, I realise we're developing educational examples here, and we want to keep the focus on the pattern, but the impression given by the full code examples isn't good. Continuing the above example, the error handling of the Composite pattern is feeble. (Static ints defined in an exception class and then if-elsed on the main class to get printable versions? Yeugh.) I'm being picky here, but this is a book about better design, and people-in-glass-houses, etc. In addition, the core concepts aren't original, and so it's this (slightly sub-standard) example code which gives the added value, or rather, should.

  • Fly-leaves
    You know what I love most about Design Patterns? The fly-leaves -- to find a pattern I open the cover, skim the list and turn to appropriate page. Brilliant for a reference title. Applied Java Patterns misses a simple trick here. A hardcover edition would also be nice. As would those nice GoF ribbons. (My apologies if there is a softcover version of the GoF book featuring neither fly-leaves nor ribbons and I've been comparing apples to oranges.)

So, overall the impression that this book gave me was of an opportunity missed. Too many little details wrong, or lacking when compared to the GoF title.

Alternate titles?

There is another Java Design Patterns title: Addison-Wesley's Java Design Patterns -- A Tutorial, by James W. Cooper (2000, ISBN 0-201-48539-7). I can't say I recommend this title either -- it's much thinner, comes with a CD, takes a more tutorial tone, but suffers many of the same flaws (sloppy editing, lack of 'flickability,' chunks of dodgy code and some bloody examples).

Sorry, but the undisputed king still reigns -- the original GoF book is still superior in almost all respects. Only a lack of recent examples, and the fact that the examples are only in C++ and Smalltalk can be called criticisms. (Details: Design Patterns: Elements of Re-usable Object-Oriented Software, by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides. Addison-Wesley, 1995, ISBN 0-201-63361-2)

If you feel that the GoF book is a bit, well, academic and intimidating for your taste then might I suggest a side order of John Vlissides's companion volume, Pattern Hatching: Design Patterns Applied (1998, ISBN 0-201-43293-5). This slim volume talks about applying patterns -- where, how, etc -- in a clear way, using a tutorial approach. The example system developed helped me "get" some of the concepts first time through. The examples are in C++.

I don't want to give the idea that there are no new Design Pattern books worth reading - for example, for J2EE work I think highly of Core J2EE Patterns by Deepak Alur, John Crupi, and Dan Malks (2001, Prentice-Hall, ISBN 0-13-066586-X).

So, to sum up, this isn't a bad book, but it does feel like a pale imitation of the GoF title, and offers very little to anyone who develops in Java but has access to the GoF book. Any publishers or wannabe authors listening? Seems like now might be a good time to think about issuing The Design Patterns Java Companion, along the lines of the existing Smalltalk title. (Hmm, maybe I should take my own advice ...)


You can purchase Applied Java Patterns from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

This discussion has been archived. No new comments can be posted.

Applied Java Patterns

Comments Filter:
  • by sisukapalli1 ( 471175 ) on Thursday September 19, 2002 @11:03AM (#4288882)
    Bruce Eckel has a book
    [mindview.net]
    Thinking In Patterns

    How does this book compare to that?

    S

    • by Anonymous Coward
      I've read most of Bruce Eckel's draft of Thinking in Patterns. It's clearly still a work in progress. Regardless, the finished work should be well worthwhile. Thinking in Java is one of the most well-crafted programming books I've read, and Thinking in Patterns is essentially a follow-up that takes the reader beyond language syntax and deeper into quality programming. Bruce is the real deal. Plus, he has a sort of open source approach to authorship, with freely downloadable versions of his works in progress and even his finished books. This naturally results in tons of peer review and feedback, delivering much higher quality writing and code than I've seen elsewhere.
    • ...it'll be longwinded, over-enthusiastic, and discarded as soon as Bruce moves on to his next programming fad.

      At least, that's been my impression so far of Bruce "Shiny objects are neat!" Eckel.
  • discussion on book (Score:3, Informative)

    by Hall and Oates ( 575706 ) on Thursday September 19, 2002 @11:05AM (#4288904)
    Here [sun.com]is a link to the archive of a discussion about this book they had in April this year at Java.Sun.com.
    Very Interesting.

  • Design Patterns (Score:4, Insightful)

    by Benjim ( 540498 ) on Thursday September 19, 2002 @11:08AM (#4288920) Homepage
    The original "Design Patterns - Elements of Reusable Object Oriented Software" is absolutely definitely the best book to describe design patterns. Ok so it has some C++ code, but if you are a Java coder worth your salt, you should be able to follow it to some extent.

    The main point is that design patterns are supposed to be language neutral! Most of the "Design Patterns in XXX" books pretty much break the idea, as they tie a pattern in to an implementation. The pattern of course is a collection of; pattern name, problem, solution, consequences, and not just some code.

    My point is that some of these books are great, and some are poor. But the original really is the only one to give you the real feeling of the patterns philosophy.
    • Re:Design Patterns (Score:3, Insightful)

      by SirSlud ( 67381 )
      Doesn't "Design Patterns" have smalltalk in it too?

      I'm a C++ guy, but I always was able to look at code in languages I hadn't programmed in as pseudocode .. I mean, you can usually tell in general whats going on. And since Design Patterns are about generalizing solutions into clearly defined patterns, I felt it was pretty appropriate that you shouldn't need to be have to compile the language in your head for examples of design pattern ...
    • Design patterns with new technology (like EJBs and servlets) are trickier to envision, that is why books like these are valuable.
    • You could not implement most of the GoF patterns in a language that doesn't support the core OO concepts ("Design Patterns for assembler" anyone ?).

      Or rather, I would suggest that most if not all languages have un-documented patterns waiting to be published - but what works well in a java environment doesn't work in assembler and vice versa.

      "A pattern is an idea that has been useful in one practical context and will probably be useful in others". (martin fowler).

      Of course there are other definitions, but most include the word "context". The language in which you are approaching the problem is definintely part of that "context" - so I think there is definitely a place for an explanation of how to implement well-known patterns in a specific language.

      Having said that, I think there's a trend towards "rip-off" pattern books which add too little value - I recently read "J2EE design patterns applied", which allegedly expands on the Core j2ee patterns book. It's not very good...

      • You could not implement most of the GoF patterns in a language that doesn't support the core OO concepts ("Design Patterns for assembler" anyone ?).

        I have a copy of Visual Basic Design Patterns. They actually manage to pull them off in VB6, though it gets a bit kludgey at times. VB.net isn't a problem though.

        For the record, the book sucks.
    • I looked at the original GoF book and gave up on it as almost unreadable. It seemed to have about half a page of mumbling followed by two pages of dry C++ code, repeat for each pattern. I just couldn't be bothered, there are so many more worthwhile things to read for the same effort. Like real code, for a start. (At least I think it was the original GoF book, it might have been some lame cash-in but I don't think so.)

      Maybe it's just a prejudice I have against long code samples in books.
      • by avdi ( 66548 ) on Thursday September 19, 2002 @03:52PM (#4291918) Homepage
        ...between software engineers and mere coders.
        • oh, fuck you, you pretentious cocksucker. At the end of the day software engineers and "mere coders" take home the same paycheck, so what the hell difference does it make?
          • Heh. I'm sure you'd like to think that's the truth. If it makes you happy, go on thinking it :-)
            • Egotism and arrogance aren't necesarily desireable corrolary features either!

              Software Engineering is a much maligned, poorly-understood and often pretended-to discipline. But that doesn't mean that most "mere coders" don't perform engineering functions (note the definition of engineering involves applying thought and ingenuity to a problem).

              And a lack of any sort of humility on behalf of "Software Engineers" isn't likely to help bridge the gap between conventional engineering disciplines and the very active world of software production.

              Instead of displaying an annoying disdain for your fellow slashdotter (whom I may not agree with but I'm not going to trash for an ego boost), can't you make your point without the attitude?
            • I'd rather be a mere coder and keep my life than be a *string flourish* SOFTWARE ENGINEER!!! and be the kind of dork that reads shit like this.

              Tech pays the bills for me, nothing more. I'm good at it and I used to love it, but now it's just a job. and I love THAT.
        • Coder - One who codes

          Developer - Also a coder but has a complex about being referred to as a "mere coder"

          Software Engineer - Coder who has read GOF and knows how to use visio, has a complex about being referred to as a "mere developer".

          Architect - Coder who has read GOF, knows how to use visio and can talk buzzwords to management thus securing the promotion. Could code, but isn't allowed to, eventually loses all perspective on facets of actual implementation. Has a complex about being called a "mere software engineer".
  • Onw would think that a good Java programmer would have at least a foundation in basic C++. Thus the examples should be easy for the Java programmer to understand. It was my experience that as a Java programmer that the GoF book was invaluable, no more so or less so than now when I do all C++ work.

    It seems that to produce a design patterns book that is language centric misses the point. They are patterns, they should be able to be implemented in any language, not just the one of the authors choosing.

    • Well, currently mono-language education seems to be the order of the day. There are Java curriculums and there will be .NET curriculums in a short while.

      And when you have no concept of separation between the syntax of a language and the semantics of a piece of code, you need a book in you language. Look on the bright side: More opportunity to make a buck selling another book in the language of the day. A .NET version of TAoCP anyone?

      Me, this just gives another opportunity to feel superior, reading Gamma et.al in the original and being able to write Software in about 20 different languages. ;-)

  • by Anonymous Coward
    I like the way it is set up. that it is clear and it has a consistant feel hrough out the entire book. It's far superrior for reference to the GoF.

    It's an easier read for most people. And it covers more patterns. Gives more code examples. And uses one language which adds conistancy.

    I think this book was very well done and I would much prefer reading it then the GoF.
  • Hrm, doesn't anyone think that these people calling themselves the "gang of four" is a bit, like, wrong? I mean, the original "gang of four", Mao's henchmen in the cultural revolution, were terrible people. I mean, it's like if some people wrote a book on 4th generation programming languages and called themselves the "fourth Reich" or something. Or created a foundation for OO design research and called themselves "Al Qaeda". ('al qaeda' = 'the foundation' in Arabic Eeh, whatever.
    • Yeah, I think that is why the 80's New Wave band Gang of Four ("I Love A Man in Uniform") failed as well--they were too hurt by the comparison you mentioned. I'd have to wait for the VH1 Behind The Music to find out for sure. Anyway, they just happened to pop onto Spinner when I read your comment. Strange.
    • THEY didn't coin the name, other people did, since it takes too long to say all 4 author's names. It's common to refer to a programming book simply by it's author's name, so "gang of four" stuck. Blame whomever first said it.

      ps, love your site
    • I think you are right - anyone who knows a little bit of history is going to picture Mao's gang of four right away. Its like a CEO refering to himself as Caesar or referring to your workplace as the gulag.

      Since /.ers aren't known to be history buffs, you're likely to to have some nazi moderator mod you down. Oops.

    • To expand on batkiwi's comment above, here's the Gang of Four [tuxedo.org] entry in the Jargon File:

      Gang of Four n.

      (also abbreviated `GOF') [prob. a play on the `Gang Of Four' who briefly ran Communist China after the death of Mao] Describes either the authors or the book "Design Patterns: Elements of Reusable Object-Oriented Software" published in 1995 by Addison-Wesley (ISBN 0-201-63361-2). The authors forming the Gang Of Four are Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides. They are also sometimes referred to as `Gamma et. al.' The authors state at http://www.hillside.net/patterns/DPBook/GOF.html [hillside.net] "Why are we ... called this? Who knows. Somehow the name just stuck." The term is also used to describe any of the design patterns that are used in the book, referring to the patterns within it as `Gang Of Four Patterns.'

      • Design Patterns got referenced so much, and Gamma, Helm, Johnson and Vlissides was such a mouthful that some wag probably called them the "Gang of Four" on account of having the same notoriety in the field of OO as the original Gang of Four had in post-Mao China.

        The only way I would find this offensive if it somehow demeaned any of the authors, which it doesn't, and it is a catchy title, and while Gamma et al are famous, they are also notorious (where is Tablizer when we need him?), so the name is fitting.

  • Help? (Score:2, Interesting)

    by billbaggins ( 156118 )
    Pardon my ignorance, but I haven't encountered this concept of "Design Patterns" (capitalized) before, and I wonder if one of you wonderful helpful egalitarian types (I know there have to be at least a couple on /.) would actually be willing to explain it for me so that I don't have to try to work it out from hints & snatches in this discussion. Please?
    • I will catch flamage for this not-entirely-flattering description, but what the hell. I got karma to burn.

      Near as I can tell, design patterns are to programming what paint-by-numbers is to art. I haven't met a gifted programmer who made extensive use of them, but they seem to be a sort of helpful template for average coders of the sort hired in legion strength for "enterprise" projects in Java and the like.
      • Re:Help? (Score:4, Insightful)

        by cmh7r ( 128304 ) on Thursday September 19, 2002 @01:21PM (#4290297)
        Don't mean for this to be the flame you expected, I'd just like to give the other side of the argument.

        > Near as I can tell, design patterns are to
        > programming what paint-by-numbers is to art.

        I can see how this comparison would occur to someone with little experience using Design Patterns. I think a better explanation is this:

        Most anyone can, given a programming problem, come up with a solution that works. If you're working on a quick and dirty piece of code for one-time use, then using patterns might not be the answer. However, its very common that people want to add new features... support new file formats, etc. Most quick and dirty designs, even by good programmers start looking really bad when new features are added. If the system grows significantly larger than the original developer expected then the design becomes completely unwieldy and they start to see how it should have been designed in the first place. The next time that developer has to design a similiar piece of software they wont make the same mistakes.

        This is where Design Patterns come in. A designer/programmer well versed in these patterns can see the end result of that first scenario before it happens. Learning design patterns helps teach good design faster. The solution to each common design problem is encapsulated in a well documented pattern.

        > I haven't met a gifted programmer who made
        > extensive use of them,

        Wow, I've met alot of people who think they are gifted programmers and write really badly designed code that works (at first) who don't use design patterns.

        On the other hand, if you judge code and design not by how much of a hack it is, but by how elegant it is, then Design patterns can make a huge difference. There is nothing beautiful about trying to cram a square peg in a round hole, even when it works.

        So, instead of "paint-by-numbers", I see design patterns as a "magic eight ball" that can tell you what problems your design will have before you even start programming. :)

        > but they seem to be a sort of helpful template
        > for average coders of the sort hired in legion
        > strength for "enterprise" projects in Java and
        > the like.

        While I am a fairly technical c++ programmer by trade, there is no reason to belittle java or "enterprise" programmers. There are some HUGE projects out there that simply cannot by done right by a few people hacking away. And I feel sorry for them when it becomes time for V2.
      • Patterns are the wheel that anyone who was ever tried to do anything serious with objects reinvents.

        Hey I got this main window object that has got all these child window widget objects -- they call that Composite. When I click on a widget, it notifies the main window -- they call that Observer. What I really want is to synch my edit box with the spin control, but I don't want to complicate the edit box by making it an Observer -- I will have the main window observe the spin control and forward that action to the edit box -- they call it Mediator (it is also known in the industry as Visual Basic).

        If GoF patterns are putting a name to commonly used OO techniques that you have probably already reinvented yourself, they are tres useful in explaining what you are doing to students, new programmers. If GoF patterns are "PHB says that I have to restructure my code to use patterns", I would agree with your flame -- they become a tool in search for a use.

        My biggest Pattern gripe is Singleton -- I have yet to see a clean implementation that does not require a lot of cut-and-paste to implement each Singleton. That darned thing is friggin hard to implement right -- Vlissides even admits in Pattern Hatching that he does not have a bulletproof C++ version of Singleton.

        • "My biggest Pattern gripe is Singleton -- I have yet to see a clean implementation that does not require a lot of cut-and-paste to implement each Singleton"

          Funny, where I work we have a singleton template that lets me just say "Singleton foo;". All such declarations (with the same ClassName) actually get you the same object. I've used it a zillion times and never had a problem. I've never looked at the code for it (never had to!), but it never occured to me that it would be very complex. I'm not dissagreeing with you, I'm just curious what's supposed to be the big problem with singleton?
        • My biggest Pattern gripe is Singleton -- I have yet to see a clean implementation that does not require a lot of cut-and-paste to implement each Singleton. That darned thing is friggin hard to implement right -- Vlissides even admits in Pattern Hatching that he does not have a bulletproof C++ version of Singleton.

          You can make a pretty straightforward Singleton template easily enough, as long as your compiler is up to speed on basic template work (which almost all mainstream ones now are, so you're fine unless you're working in the legacy world). I refer my honourable friend to Modern C++ Design by Andrei Alexandrescu for one simple possibility (and many other useful tricks with Singletons and templates generally, if you're compiler's up to it).

    • Re:Help? (Score:3, Informative)

      by XMunkki ( 533952 )
      Design patterns describe some common code design problems, give a solution to it and analyzes the problem and the solution. So in short when you are facing a structural design problem (like "how should all my GUI widgets interact in the GUI toolkit I am writing"), you might wanna check these out.

      Usually programmers "use these" without even knowing them (after all, they are common solutions to common problems).
    • Re:Help? (Score:4, Informative)

      by Dr. Awktagon ( 233360 ) on Thursday September 19, 2002 @01:17PM (#4290239) Homepage

      Here is a FAQ [oswego.edu].

      Patterns are named solutions to problems, which resolve constraints in a a given context. They aren't rigid (like, say, a template), they are abstractions of commonly occuring problems and solutions that occur in programming. For instance, "one object needs to do something to another group of objects" might be a problem, and the Visitor pattern might help you find the solution. The code you use to implement the pattern might be radically different than the code someone else uses, but underneath the pattern is the same.

      They come from Christopher Alexander's work in architecture, where he saw the same recurring patterns in architecture and felt that they arose from deeper truths about people and societies. An example of Alexander's architectural patterns: "Intimacy Gradient", which is a pattern that describes how the front of a home is less personal and intimate than the back of a home. For instance you might leave your stuff laying out in a back room, but you keep the front room neat for guests.

      Very interesting from a philosophical point of view as well, and helps you to better understand why some programs/houses/objects are pleasant to work with, and others are a chore.

    • The basic idea is that certain problems arise frequently in designing code, and often people come up with very similar designs to implement the solutions. This gives rise to two ideas.

      1. It's handy to have a name for these common idioms, so you can discuss them without having to waste effort defining them all the time.
      2. One person may implement things slightly differently to another, to cater for a problem or possible extension that someone else didn't notice. It's useful to have a baseline solution that's been well-reviewed and is known to handle common problems/extensions well.

      A design pattern is simply a named, streamlined solution to a common problem.

      Many people, not least Gamma et al. in their book Design Patterns (Addison-Wesley, 1995, IIRC), suggest that if you find the same sort of idiom solving similar problems in two or three different places, then it's likely to be worth looking for the underlying common idea behind those solutions, streamlining and naming it, and thus producing a new design pattern. Some design patterns are quite general and occur in many OO designs in diverse fields, and others occur frequently in a particular field but are irrelevant elsewhere.

      Design patterns are basically useful in two ways.

      1. Up front when you're doing initial design, you might recognise your situation as being similar to a pattern you know, and thus get an idea about how to design the code to meet the situation.
      2. In code reviews and refactoring exercises, if you've wound up with something similar to a common pattern, it pays to check out the known issues with that pattern, and see if any of them arise in your code (in which case, you can use the known workarounds/design changes to fix them). If you've come up with a different solution to the same problem, maybe the design pattern handles cases you don't; if so, you might pause to convert your design to use the pattern instead.

      The final important thing to remember is that design patterns are never a goal in themselves. Code is not good just because it follows patterns or bad just because it doesn't. The benefit of patterns is simply that they make it easier to do what you might have done anyway, but probably with less effort, more confidence and better results.

  • by gabbarsingh ( 207183 ) on Thursday September 19, 2002 @12:05PM (#4289371) Journal
    Java Companion [patterndepot.com] is a free (PDF) download of a good treatment on the subject. As a practicising java developer there's no substitute for the GoF Design Patterns especially the discussion on each pattern. But sometimes it's hard to gather the full meaning because a C++ demonstration is used replete with multiple inheritance or even just inheritance that may be realised in Java as composition. With Java, one requires little bit help, some lateral thinking to come up with an equivalent. The download has helped me immensely.
    • A newer version of the same document can also be found in book form at Amazon [amazon.com].

      It is nearly the same document, only with a few added items, and both are written by James Cooper. It is a very good companion to the GoF book!

    • I have this guy's book. "Java Design Patterns: A Tutorial" It is the worst Patterns book I have ever read. If you don't believe me just check the reviews at amazon. I've you're looking for thye definative Java Patterns, I suggest looking at another author. Mark Grand also sucks. So far the Stelting-Maasen book is the best I've seen, after the GoF Book.

  • It would be nice if the book reviewers gave the scale that they rated books on (or were required to use a standard rating system). It is hard to compare reviews when one reviewer uses A - F, the next uses 1 - 5, and the next uses 1 - 10.

  • Applied Java Patterns is an adequate Design Patterns reference for those who must have a Java version of the classic Gamma et al (aka Gang of Four, or GoF) Design Patterns

    If you feel you need the Java version of the original GoF (gang of four) book, I have a recommendation: Skip the book, and buy Eckel's "Thinking in Java," because you have some catching up to do if you can't translate the original design patterns into Java (or any other OO language, for that matter).

    Too many developers use design patterns as either (1) a crutch due to poor design methodology or (2) sparkle and glitter in order to impress the boss with an otherwise sound design methodology. Learn the language first, work with the language, and write some software before worrying about design patterns. The original GoF book will work with any OO language, but you will have to supply the necessary skills to get the job done. Another design pattern book isn't going to help you.
  • Even though I usually use Java (augmented with Common LISP, Scheme, Python, C++), I bought the Smalltalk version of the Patterns book - it is excellent.

    I have no problems applying the Smalltalk version to Java, etc.

    Really, I think that it is best to be language agnostic: happily use any language someone pays you to use.

    my own project:I like to write (a lot!) and I am just starting a new Free Web Book project that I not-so-humbly call "The Software Design Book" that uses what I call "light weight" UML (i.e., only use case, class, and sequence diagrams) and lots of my own philosophy. Anyway, an early version will join my other two free web books on my site in a week or two.

    -Mark

    • Really, I think that it is best to be language agnostic: happily use any language someone pays you to use.
      You should charge extra for some languages, such as Intercal [tuxedo.org].
  • by johnfoobar ( 258419 ) on Thursday September 19, 2002 @12:46PM (#4289870)
    Design Patterns should be put in perspective. There are not the be all and end all that some Java/OO zealots make them out to be.

    Propoganda
    Design Patterns in Dynamic Programming [norvig.com]
    "Design Patterns" Aren't [plover.com] (google cache link [google.com])

  • I guess I am alone in thinking that for the Singleton pattern, this sort of coding is sufficient:

    public class Something {
    private static Something s = new Something();
    private Something() {}
    public Something getInstance() { return s; }
    }

    You see in Java, unlike C++, we have a classloader that manages the loading (and thus creation) of a single instance of a class. If you are calling Something.getInstance, presumably the class-loader will then load the Something class at that time, instantiate a sole instance, and return it to you, without having to worry about the details of thread-safety and creating multiple instances.

    Anyway, using the Singleton pattern is not entirely "good programming practice", as it is often used to create "Global Variables" in disguise.

  • by Tablizer ( 95088 ) on Thursday September 19, 2002 @12:56PM (#4289993) Journal
    GOF-style patterns get carried away with "using code to model your nouns". I find using relational techniques and tables superior because they do not depend on the physical structure of code (beyond relational formulas), but rather use as-needed "virtual patterns". It is like the differences between doing calculus by counting rectangle approximations under the curve and diriving dirivatives via formula transformation. GOF is a bunch of rectangles hand-weaved together in my viewpoint; a bunch of classes hand-indexed together the old-fashioned way. I would rather let the database engine and compact formulas do most of the weaving for me.

    In procedural/relational design, the programming code is less tied to the "noun-model". Thus if you want to change the noun model or have multiple simultaneous noun models in play, the code does not need large-scale overhauls in its structure. This makes p/r more change-friendly IMO, and most software expenses are on maintenance, not creation.

    If you tie your code tightly to noun models, like GOF and OOP tend to do, then your code needs more rework if you change your noun model/relations. Pretty simple.

    Paul Graham has made similar comments about patterns, although he uses relational's cousin: functional programming and set theory, to do similar "virtualizing". (In essence, he uses relational-like formulas in LISP.)

    More reading on my opinion of GOF-style patterns:

    http://geocities.com/tablizer/prpats.htm

    http://geocities.com/tablizer/whypr.htm

    What we have in this slashdot story is TWO overhyped techologies: Java and GOF-like patterns. A 2-for-1 bargain. PHB's and fad chasers will love it.
    • Can you recommend a language/relational dB combination under Windows that allows you to do what you advocate, including using relational tables to dispatch code?
      • (* Can you recommend a language/relational dB combination under Windows that allows you to do what you advocate, including using relational tables to dispatch code? *)

        I said *nothing* about dispatching code here from tables. In practice, it is not needed/helpful that often. The relationship between rows and behavior often does not stay one-to-one over the long-run. Thus, there is little or no benefit to tying them one-to-one most of the time.

        However, just about *any* dynamically-typed or type-free language could do such. If you can hook say Python or Perl or LISP to a RDBMS, then you can do it. Heck, even MS-Access has an Eval() function IIRC if you want/have-to use that P.O.S.

    • I found the ideas on your site to be really interesting... Obviously, you are taking exception to the idea of OOP and not patterns. I certainly see the value you in your approach. You appear correct that in some circumstances, a change in overall design could be realized just as quickly using a relational model (in some cases.) (I'm sure you would argue more quickly, but I am not convinced of that)

      Where it appears to fall short is in the area of reuse. Your code is written extremely specifically for the task at hand and does not seem like it could be moved over to a new domain. (I haven't had a chance to browse all of your articles so maybe you address this.)

      The functional programming models you talk about tend to be more similiar to the OOP approach (heavy use of polymorphism) only using far less "nouns".

      Anyways, thanks for the link to your site which seems to be a really interesting resource.
      • Where it appears to fall short is in the area of reuse. Your code is written extremely specifically for the task at hand and does not seem like it could be moved over to a new domain.

        I would have to see a specific example of a something in OOP that is better at being reused than a procedural/relational approach.

        Note that "reuse" seems to be dropping off the list of "standard OO benefits" in OO circles. I have heard quite a few OO fans say, "reuse is not where it's at". And, I have cited some Wiki discussion groups and a Dr. Dobbs article that lean this way also. (Just follow the "myths" link on my website to "reuse".)

        I am not sure exactly what the benefits of OOP are *supposed* to be. Some OO fans lean toward it being better to mentally grok, while others insist that it makes software more "change-friendly" (but not necessarily easier). Of course, I disagree with both of those claims.

        Consistency of both design methodology and benefit reasons in the OO world is sorely lacking.

        I personally think OOP is popular (among the S.E. elite) due to these two factors:

        1. Some people just seem to think better under OOP due to their *particular* brain/phsycology.

        2. Written OO material tends to overemphasize certain change patterns that OO is particular good at, at the expense of change patterns that OOP has a tougher time with. IOW, they present a non-representative (frequency-wise) list of change problems, and then conveniently show OOP "fixing" them.
        • > I would have to see a specific example of a
          > something in OOP that is better at being reused
          > than a procedural/relational approach.

          Although I'm not primarily a java programmer, a nice example that jumps out at me would be Java applets. You can simply inherit the majority of functionality that you do not need to change from code provided in the framework and simply provide your own implementation changes where appropriate. (I was going to use MFC as an example, but it sucks so I might have been disproving my own point). This amounts to creating an entirely new "noun" with fairly complex functionality in very few lines of code. Perhaps the cost here is knowing what does go one behind the scenes.

          Certainly the same effect could be achieved by using OO-like practices in a proceedural (or possibly relational?) context, but it would not be nearly as elegant. I believe this is the case with the majority of OOP benefits.

          Furthermore, designing using very specific "nouns" has the side affect of predisposing your code to reuse. When you go to program something else and need that same "noun" you already have it. I have found that proceedural programmers tend not design their software in a way that allows it to be immediately applicable to other tasks.

          > 1. Some people just seem to think better under
          > OOP due to their *particular* brain/phsycology.

          hmmm.. never gave too much thought to this, but it seems most programming paradigms use some kind of analogy model to help their users. Nonetheless, if what you say is true, you are giving a good arguement FOR OOP.

          > 2. Written OO material tends to overemphasize
          > certain change patterns that OO is particular
          > good at, at the expense of change patterns that
          > OOP has a tougher time with. IOW, they present
          > a non-representative (frequency-wise) list of
          > change problems, and then conveniently show
          > OOP "fixing" them.

          I'm definitely interested in what you're suggesting. Do you have any references that catalog some of these different problems OO struggles with (and other paradigms do not)?

          Most of the opinions that I have are based on either studying or maintaining code written with various approaches. I'm by no means an OO zealot and can appreciate elegance in any form. However, the OO code I've seen *tends* to be more readable/elegant than most proceedural. And the bad OO code is sometimes a result of using alot of proceedural ideas (or in some cases, design problems that could be fixed w/ GoF patterns :)
          • (* Although I'm not primarily a java programmer, a nice example that jumps out at me would be Java applets. You can simply inherit the majority of functionality that you do not need to change from code provided in the framework and simply provide your own implementation changes where appropriate. *)

            Inheritance is simply a form of "overriding" defaults. In p/r you can also make it so that blank table cells or that not supplying a named parameter result in some default behavior. It is not more code than inheritance.

            But where inheritance fails is when changes are no longer hierarchical or not mutually-exclusive. You cannot easily "grab" behavior or attributes from a peer branch on the inheritance tree without a lot of code shuffling. P/r techniques allow one to use sets, for example, instead of trees if changes progress in a non-tree fashion. OOP requires a complete code structure change to go from tree-based feature management to set-based feature management.

            IOW, p/r does not make the code structure resemble your currently-used data structure. That way you can change the data structure characteristics/shape without major code overhauls. You may have to change an expression or two, but you don't have to *move* large chunks of code around.

            (* Furthermore, designing using very specific "nouns" has the side affect of predisposing your code to reuse. *)

            I addressed "reuse" in a sister message.

            (* I have found that proceedural programmers tend not design their software in a way that allows it to be immediately applicable to other tasks. *)

            I find procedural programmers do all kinds of different *bad* crap if you let them. (Same with OOP.)

            I will agree that OOP training *by tradition* encourages people to pay more attention to software engineering issues. However, the same could be done with p/r techniques, but is generally not.

            It is like the Hypocratic Oath being part of medical training, but not say jet mechanics. It is tradition, not need, that makes it that way.

            Are going to argue that bad OO is better than bad p/r? I know some OO fans who even disagree with this. They have some OO-gone-bad horror stories of their own. IMO, bad p/r is at least more consistent than bad OO in practice. OO training makes stupid programmers have more oddball ways to obfuscicate OO code.

            Thus, we should probably compare good OO[1] to good p/r rather than bad to bad.

            [1] If there is such a thing :-)

            (* Nonetheless, if what you say is true, you are giving a good arguement FOR OOP. *)

            I did not say *all*, or even *most* brains are a better fit for OOP. There is just no decent data on this issue. It may not be practical to pack rat a language with every paradigm and construct just incase somebody thinks a given way.

            (* I'm definitely interested in what you're suggesting. Do you have any references that catalog some of these different problems OO struggles with *)

            I suggest you poke around my website. A starting point may be:

            http://geocities.com/tablizer/change.htm#people

            (AKA, "people types")

            (* However, the OO code I've seen *tends* to be more readable/elegant than most proceedural. And the bad OO code is sometimes a result of using alot of proceedural ideas (or in some cases, design problems that could be fixed w/ GoF patterns *)

            Well, I would be interested in seeing something specific, hopefully from my familiar domain (custom biz apps), and not say Chemistry. I have no feeling for the change patterns of such industries.

            "Elegant" is often subjective, BTW.
    • It is intriguing to see such a criticism of the patterns, because to me the great personal breakthrough was seeing how the patterns enabled one to "objectify" a verb. As I see it, many of the patterns seem to do this: Iterator, command, strategy, and I don't have the book on hand but several others as well.

      Each of these bundle a verb: The iterator bundles "traversing the data structure", the command bundles some piece of functionality, the strategy does the same thing but inverted relative to the command.

      To me, the noun-like patterns were interesting and sometime useful (I always though "flyweight" was cool), but I've gotten a lot more milage out of the verb-like patterns.

      I'll read your critiques here in a bit, but I would be curious about any response or reaction you'd have to my thoughts that many of the patterns are verb patterns. (Feel free to privately email if you don't want to do this on Slashdot.)
      • I'll read your critiques here in a bit, but I would be curious about any response or reaction you'd have to my thoughts that many of the patterns are verb patterns. (Feel free to privately email if you don't want to do this on Slashdot.)

        Most of the verb-centric patterns seem to be reinventing the database in my observation. For example, "iterator" may *duplicate* the interface and implementation of iteration for every class that needs it. In the p/r world, you don't have to reimpliment it over and over again. Plus, iterator lacks expression-based filtering, joins, sorts, indexing, etc. without yet more hand-coding and interface expansion.

        Every participant class ends up carrying around the "baggage" to be able to do otherwise common, database-like operations on it. Sure, there are ways to factor some of this to a central spot, but it tends to have other side-effects, and your central package is a hand-built half-ess database anyhow. You might as well byte the bullet and do it right.

        We would probably have to visit (pun) a specific example together. You mentioned taking this to email.
  • I looked at this book, and decided not to buy it because it didn't really offer that much other than implementations of the GoF patterns in Java, and to be honest, they were basically crap. I'd say that this book might actually do more harm than good if it were being used in a teaching environment.

    I noticed that there are some comments criticizing the fact that the GoF book has examples in only C++ or smalltalk, which is perhaps what promted the authors to produce this book.

    The thing is though, the GoF text is trying to express some pretty fundamental programming concepts, that can be readily implemented in ANY language - granted it helps if your choice language supports inheritance/polymorphism.

    The bottom line is that C++ is basically similar to smalltalk which is basically similar to Java which is basically similar to C#.

    Any programmer worth his salt should be able to understand what the examples in the GoF book are trying to get across if he knows even one of those languages. They're not _that_ different. And besides, it might help if you have to look at the code a little harder.

    Now if the examples were written in some language that was an absolutely radical departure from your standard OO language, say Lisp for example, then I could understand some complaints, but seriously, the language is not that big of a deal.

    Just for fun, the language whiners should check out Donald Knuth's "The Art of Computer Programming" series - he defined his own language for those examples. His language is kind of like assembly, but it kind of isn't. Doesn't match any language today, but I bet you won't be able to find anyone who will say that those books are not an absolute treasure trove of information, despite the implementation language.

  • For those unfamiliar with double checked locking, it's explained here [umd.edu].

    The basic claim, is that code like this:
    public class Singleton{

    private static Singleton instance;

    public Singleton getInstance(){
    if (instance == null){
    synchronized(Singleton.class){
    if (instance == null)
    instance = new Singleton();
    }
    }
    return instance;
    }

    }
    doesn't work, and the only way to fix it is put the first (instance == null) check into the synchronized block, incurring the synchronization penalty every time the method is called.

    You could also simply avoid lazy initialization and instantiate the singleton when the class is loaded.

  • Has anyone tried the Design Patterns Java Workbook by Steven John Metsker?

    It's sitting on my desk right now. I'm liking it...
  • "you won't see discussion on why double-checked locking implementations of the Singleton pattern don't work. "
    ... nor should you.

    Two scenarios:
    1.There must be only one Singleton instance at a time, and if this rule is broken it has negative consequences for the correctness of your application, or a large performance overhead.

    Make the getInstance() method synchronized.

    2. A short-lived second instance is not a huge problem.

    Don't worry about it.

    There is far too much emphasise placed on the avoidance of synchronization, when greater gains can be made by optimizing other things like your algorithms. The performance cost has been reduced in VMs in the last few years anyway. The double locking idiom existed purely to avoid synchronization, and never worked anyway.

    I heard a great quote at JavaOne a few years ago: "The cost of synchronization is less than the cost of stupidity".

1000 beers served at a Twins game = 1 Killibrew

Working...