Slashdot Mirror

← Back to Stories (view on slashdot.org)

J2EE Design Patterns

Posted by timothy on from the squint-and-blur dept.

whirlycott writes "In case you're not up to date on what design patterns are, let's do a quick crash course before we jump into a book review on the subject. Design patterns were thrust into the software development mainstream by the book Design Patterns in 1995 (aka the GoF book). A pattern involves three components: first, a description of a generalized recurring problem; second, an abstract solution that is generally accepted; and third, a name for the sake of convenience. Patterns save time and effort by supplying developers with a shared language when discussing common problems. O'Reilly's new J2EE Design Patterns book is a timely, easy-to-read catalog of architectural patterns specific to the J2EE platform." Read on for the rest of whirlycott's review. J2EE Design Patterns author William Crawford and Jonathan Kaplan pages 368 publisher O'Reilly rating 8/10 reviewer Philip Jacob ISBN 0596004273 summary Detailed collection of patterns suitable for beginners or architects alike

If you are working on frameworks, integration projects or system components, it is my belief that you'll almost certainly pick up some ideas from this book. J2EE Design Patterns is organized according to the different layers that you might find in a multi-tier architecture: presentation, business, database, messaging, and others. Consequently, if you're a JSP developer on a project team, youll be able to get some ideas for how to organize your work as well as how to interface it with, for example, controllers, if you're following an MVC framework. Or, if you're integrating various distributed non-Java systems, you'll want to read the chapters on Business Tier Interfaces and Enterprise Concurrency.

Judging by my friends' bookshelves, another popular Java patterns book is Core J2EE Patterns. If you already own this book, you will find that this new offering from O'Reilly doesn't contain as many patterns per se, but seems to go into a greater level of detail describing each pattern and supplementing it with more code samples. A nice feature of the O'Reilly book is that each pattern gets ample coverage in enough detail for you to understand the actual problem, the causes and -- equally importantly -- how to put a solution into place. Each pattern is described using some UML notation and code samples (Chapter 2 contains a UML primer).

One of the problems that I've encountered reading books on the subject is that some steer so deeply into abstraction that they become hard to understand. Others are so stylistically repetitive that trying to read them becomes mind numbing. Fortunately, neither problem surfaced during the time that I spent reading this book. The authors avoided the visual repetition of the traditional Problem / UML / Goal / Actors format that other books follow by moving this type of description into an appendix. That lets the body of the book flow more easily and also supplies the reader with a handy quick reference in the back pages.

Do I have any complaints? Well, this book certainly doesn't suffer from any fatal flaws. But it seems that an acknowledgement of the popularity of certain components could have been included. For example, while specific MVC frameworks, like the ubiquitous Struts, were mentioned, Object-Relational mappers were not; I read some of the chapters and winced at the code samples that manipulated SQL strings and felt grateful that I'm using the wonderful Hibernate O/R mapping engine. Of course, for various reasons, some readers won't be able to use tools like these, and a book about patterns has to maintain a certain level of abstraction in order to maintain any lasting credibility. But the section on Object-Relational Mapping doesnt even mention that a class of tools exists without the use of EJB CMP (Container Managed Persistence). Thats a real shame, because manually moving data from the object world to the relational world and vice versa is time-consuming and error-prone (and frequently unnecessary) work.

It's a good book, with 285 pages of text and 53 pages of appendices. I've owned it for four days, and I've already managed to steal some of these ideas for the projects I'm working on.

Philip Jacob works for Eyeglasses.com. You can purchase J2EE Design 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.

130 comments

  1. Here's a design pattern: by deadlinegrunt · · Score: 3, Funny

    I call it the tag delimeter pattern.

    --
    BSD is designed. Linux is grown. C++ libs
    1. Re:Here's a design pattern: by tomknight · · Score: 1
      Yeah, but the front page looks so pretty now...

      Tom.

      --
      Oh arse
  2. Still Not Real Clear on Design Patterns... by ViolentGreen · · Score: 1

    So is a Design Pattern just a clearly defined common problem and a general, language-independent, algorithm for solving the problem?

    I have never heard that term before...

    --
    Not everything is analogous to cars. Car analogies rarely work.
    1. Re:Still Not Real Clear on Design Patterns... by Evil+Adrian · · Score: 2, Informative

      I believe it's specific to OOP... basically, "design patterns" are about taking common problems, finding a pattern, and coming up with a (generalized) solution dealing with composing and managing objects, and ways of coordinating the objects.

      Did that make sense? I haven't had enough caffeine today.

      --
      evil adrian
    2. Re:Still Not Real Clear on Design Patterns... by humandoing · · Score: 2, Informative

      That seems to be the general take on the matter.

      For example, the Gang of Four book (Design Patterns: Elements of Reusable Object-Oriented Software) has a ton of patterns that it discusses, and the language that it happense to use to illustrate the solutions to these "problems" is in SmallTalk... Not a lot of people were using Java in 1995, and I was still in grade 10 programming Pascal ;). It has 3 broad categories of patterns that it defines as Creational, Structure, and Behavioral...

      For example, one of the Behavioral patterns defined in the Book is "Iterator". This is defined as "...a way to access the elements of an aggregate object sequentially without exposing its underlying representation". This is an extremely simple example, but it is clear that this is a common problem, with common solutions, implemented in dozens of programming languages (eg: java.util.Iterator).

      Hope thats informative!

      --
      java guy, tech blog...
    3. Re:Still Not Real Clear on Design Patterns... by j3110 · · Score: 4, Insightful

      Basically there are common themes in problems, and patterns help with the theme of the problem, not the problem itself. For example, I could want to centralize and pool objects for some reason. The design pattern to solve this kind of problem is basically to make constructors private and use "Factories" (static member functions) that return the objects using static data to keep track of them.

      Pattern can be a misleading word because it has too many meanings. You could interpret design pattern as commonalities in design or as a design template (like sewing involves working off of a pattern). It's closer to the first definition than the second.

      Just don't follow a pattern that you don't understand exactly how works. You'll end up with more problem than solution. That's why I usually don't like pattern books. Unless you read them like you would a chess book and try to figure out how/why it's a mate-in-2, then you aren't going to get any real benefit from them. Chances are if you can understand how/why, then you didn't need the book to begin with. There's a slim chance that you'll run into a problem and have not used a more optimal solution because you didn't read one of these books, but I don't think it's all that great. Design patterns should be taught in school as exercises for the common problems they'll run into, not really a place to start when trying to solve a problem.

      --
      Karma Clown
    4. Re:Still Not Real Clear on Design Patterns... by Space+cowboy · · Score: 3, Informative

      Pretty much. For example, the 'Singleton' pattern is where you may have a single resource you want to share between multiple objects, without making a copy of the interface to that resource. Typical behaviour is to have a static getInstance() method which checks to see if a static object already exists and returns that instead of a new object. The contructor is usually kept private/protected to enforce the pattern.

      The first time you read a "patterns" book, you'll sit thinking "but that's obviously how you do it". The advantage is that the pattern books generally spell out *why* it's the best solution, and you can then apply that knowledge in other situations.

      Personally, I found 'Design patterns' hard reading. The concepts weren't hard, but the prose was painful. 'Patterns in Java' (not to recommend it too much - I mentioned it in another post as well :-) is far more readable, but there's a lot of crossover.

      Simon.

      --
      Physicists get Hadrons!
    5. Re:Still Not Real Clear on Design Patterns... by butane_bob2003 · · Score: 2, Informative

      Not a algorithms exactly, design patterns are described by class diagrams. Design patterns generally describe behavioral, structural and creational aspects of objects. Algorithms are concrete implementations of solutions to problems.

      --


      TallGreen CMS hosting
    6. Re:Still Not Real Clear on Design Patterns... by Mikkeles · · Score: 2, Informative
      Software design patterns are an offshoot of Christopher Alexander's architectural patterns as described in his book: A Pattern Language. (E.g., reviewed here and here.)
      Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. -- ChristopherAlexander
      --
      Great minds think alike; fools seldom differ.
    7. Re:Still Not Real Clear on Design Patterns... by soundofthemoon · · Score: 2, Informative

      The term pattern may not be the best choice of a word to describe the concept, but it comes close. Just like you can have a pattern for a garment and then use that pattern to make a shirt from any type of fabric, design patterns supply standard solutions that can be used to solve common problems, but in an easily customizable way.

      When the Gang-Of-Four book Design Patterns first appeared, there was a lot of talk about it at OOPSLA that year. I'd been a lucky witness to the birth of the concept a year or two previously. There was a lot of talk among Smalltalkers at Apple and everyone was reading Christopher Alexander's book A Pattern Language. By the time the Gang published the book, the meme had mutated and most people didn't get the underlying concept.

      The OOP software community was struggling for a metaphor for understanding patterns. Many people latched onto the idea of the chip catalog. Like you can grab a catalog for SSI and LSI chips and find the OR gates or shifters you need, wire them together and voila you have a circuit board. Programmers want that kind of reuse, and are tired of having to reinvent the wheel every time they want to go for a ride.

      But patterns can't be reused in the same way that chips can. I think API calls are a more equivalent concept to chips in a catalog. Patterns are more like things like "power suppy" or "transmitter" or "step motor". They exist in the design space above the chip or API call. They show how to use the more granular pieces to assemble higher-level solutions.

      Working in Smalltalk, some of us noticed there were ways we would use classes, objects, inheritance, and references that we would repeat over and over. We began to make up names for them so they were easier to talk about. I remember encapsulator was one of the early names that was used a lot (it's an object that intercepts all references and messages to another object).

      Design patterns provide a vocabulary for talking about, and more importantly thinking about, the ways that we've learned to solve common problems. This shouldn't be surprising, since the origin of the term was something called a pattern language, and languages have vocabulary. If you don't have a word for something, it's hard to reason about it. Try thinking about an arrangement of buildings if you have no concept of "community" or "town". Patterns supply the concepts for reasoning about design problems.

    8. Re:Still Not Real Clear on Design Patterns... by mark_lybarger · · Score: 1

      i'd beg to differ that these are oop specific. there's design patterns all over the place. there's a problem, a common solution, and general name.

      take freeway exists. there's different freeway exiting implementation depending on the problem at hand. very high traffic, you'll see the four circles around the exit. lower traffic, and possibly just straight exit and entrance ramps w/out the loops.

    9. Re:Still Not Real Clear on Design Patterns... by KillerCow · · Score: 1

      So is a Design Pattern just a clearly defined common problem and a general, language-independent, algorithm for solving the problem?

      Remove "clearly defined." Sometimes moving from the problem to the pattern is not clear, but going from the pattern to the problem should be clear.

      Change "algorithm" to "model."

      Definitions from Google

    10. Re:Still Not Real Clear on Design Patterns... by Evil+Adrian · · Score: 1

      I would argue that "freeway exit" represents an abstract object, of which are derived different concrete types... ;-)

      --
      evil adrian
    11. Re:Still Not Real Clear on Design Patterns... by EastCoastSurfer · · Score: 1

      I believe it's specific to OOP

      OOP Design patterns are the only patterns specific to OOP :)

      Deisgn patterns were first developed by an architect named Christopher Alexander. In his book A Pattern Language he used them to help present common design problems and solutions to other architects. Patterns are as much as a best practices book as they are a communication tool.

    12. Re:Still Not Real Clear on Design Patterns... by EastCoastSurfer · · Score: 2, Insightful

      Chances are if you can understand how/why, then you didn't need the book to begin with.

      I beg to differ. Design patterns are not just about showing problems and solutions. They are also to help for a common vocabulary among the people who use them. Instead of me having to explain that I used a pool of small objects with intrinsic and extrinsic state to solve this problem I can just say Flyweight.

      Design patterns should be taught in school as exercises for the common problems they'll run into, not really a place to start when trying to solve a problem.

      Design patterns are the perfect place to start solving a problem. As you break a problem down into smaller parts you can start solving pieces just by applying a pattern. If everyone on the team is knowledgable of patterns the "simple" parts of the architecture can be dealt with quickly. This leaves more time to work on the complex architecture issues.

    13. Re:Still Not Real Clear on Design Patterns... by RetroGeek · · Score: 1

      I remember encapsulator was one of the early names

      Hmm, I have used this, but I always called it a wrapper.

      That is it wraps around another more complex class (or classes) to provide an easier (and usually with pre-defined behaviour) interface.

      --

      - - - - - - - - - - -
      I am a programmer. I am paid to produce syntax not grammar. Deal with it.
    14. Re:Still Not Real Clear on Design Patterns... by soundofthemoon · · Score: 1

      The 80s use of the term encapsulator was an object that not only wrapped another, but mimiced it's interface. So externally you couldn't tell you were using an encapsulated object. It was a way of adding functionality by composition rather than inheritance. The trivial example is an encapsulator that logs all messages, which is perhaps useful for debugging. What you are talking about is more like a Facade pattern.

    15. Re:Still Not Real Clear on Design Patterns... by RetroGeek · · Score: 1

      So externally you couldn't tell you were using an encapsulated object.

      Isn't that like "extending" the class?

      Of course you must then instantiate the extended class to use it.

      Facade pattern

      Sigh....

      I wish we as an industry could just STOP coming up with new names for the same old things.

      --

      - - - - - - - - - - -
      I am a programmer. I am paid to produce syntax not grammar. Deal with it.
    16. Re:Still Not Real Clear on Design Patterns... by NickFitz · · Score: 1
      Isn't that like "extending" the class?

      He already said not:

      adding functionality by composition rather than inheritance
      --
      Using HTML in email is like putting sound effects on your phone calls. Just say <strong>no</strong>.
    17. Re:Still Not Real Clear on Design Patterns... by GreggBert · · Score: 2, Interesting
      Anyone who thinks design patterns are only applicable to OOP should really read the book "A pattern language - Towns, Buildings, Construction" by Alexander, Ishikawa, Silverstein, Jacobson, King and Angel (c) 1977 (ISBN 0-19-501919-9). It is the second in a trilogy of books on Patterns, what they are, how to recognize them and how they are applicable to municipal planning and building systems.

      It's pretty interesting to see where some of these modern day architects got their ideas and that patterns occur in things all around us in our everyday lives.

      It's also required reading for anyone REALLY serious about playing Sim City.

      --


      If you don't understand anything I post, please accept that I ate paste as a small boy...
    18. Re:Still Not Real Clear on Design Patterns... by RetroGeek · · Score: 1

      Note the quotes around extending.

      If you are using the same method names to do the same functions, albet with added functionality, then in effect you ARE extending the class. Just not formally.

      Moreover it could be argued that this adds to the memory footprint and to processing time, as the new class must be instantiated, then it in turn must instantiate the class it is a mimic for.

      --

      - - - - - - - - - - -
      I am a programmer. I am paid to produce syntax not grammar. Deal with it.
    19. Re:Still Not Real Clear on Design Patterns... by NickFitz · · Score: 1
      then in effect you ARE extending the class

      From a pragmatic point of view, yes. I would prefer to say that the class has the same method signature. Note that, for example, an encapsulating class of this kind could not be used in the same place as an instance of a superclass of the wrapped class. So taking a simple example:

      class Ape() {
      ...
      }

      class Bonobo extends Ape {
      ...
      }

      class BonoboWrapper {
      private Bonobo wrappedBonobo;

      public void BonoboWrapper(Bonobo myApe) {
      this.wrappedBonobo = myApe;
      }
      }

      then a method expecting an Ape would work with a Bonobo instance, but not with a BonoboWrapper instance. As to which is more appropriate, it depends on the circumstances. Better minds than mine have debated this extensively here and here, so I'm not going to commit myself and look even more stupid :-)

      (Sorry about losing the indentation on the code; today's too short to work out how to get round /.'s formatting vagaries.)

      --
      Using HTML in email is like putting sound effects on your phone calls. Just say <strong>no</strong>.
    20. Re:Still Not Real Clear on Design Patterns... by RetroGeek · · Score: 1

      Better minds than mine have debated this extensively

      Mine too :-))

      There are subtleties to this OO business....

      --

      - - - - - - - - - - -
      I am a programmer. I am paid to produce syntax not grammar. Deal with it.
  3. Another useful patterns book by Space+cowboy · · Score: 2, Informative

    though not J2EE (only "standard" Java) is 'Patterns in Java', coming in a few volumes, though I rate the first one highest, the other two get increasingly abstract/uncommon. When does a pattern become an occurrence ...

    Simon

    --
    Physicists get Hadrons!
  4. hear hear by m0smithslash · · Score: 3, Interesting

    Conincidently a co-worker/cow-irker of mine just borrowed my copy. The nice thing about it is it gives some names to ideas a lot of us already use, making it easier to talk about them.

    --
    Your friend and well-wisher
    m0smithslash
    http://www.ferociousflirting.com
  5. Most popular Java pattern by Anonymous Coward · · Score: 3, Funny

    is the buzzword pattern.

    Maybe I'm getting old, but at one time we just wrote systems that worked without regard to what was in fashion at the time.

    Scottie: Cap'n - I confluckulated and strutified the entity beans, and I'm given 'er all she's got!

    1. Re:Most popular Java pattern by FortKnox · · Score: 1

      Patterns aren't a "fashion". In fact, I bet you wouldn't have commented on this if it concerned C++ patterns.

      That's right, I'm accusing you of being a COMPUTER LANGUAGE BIGOT!

      Can't we all just get along?!?!

      Seriously, though. Patterns are nice to have for architects, and since they are 'reused' its easier for developers to "create" the ideas the architect develops.
      And patterns have been around too long to be considered a 'fad' (things like Extreme Programming is what I'd argue is/was a 'fad').

      If you are an XP lover, I don't mean to start an arguement, its just how I see the field...

      --
      Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
    2. Re:Most popular Java pattern by Anonymous Coward · · Score: 0

      Your systems were also almost certainly written by a team of 4 and had no requirements of 100% failover, etc. Or maybe not, but either what this post would make one assume as such.

      Pretty typical post of the typical Hippy style, Dogmatic Unix Nerd ... and as much as I can respect those types, it is easy to disregard them when talking about $100 million systems, such as the J2EE /struts/pattern driven project I am currently on. Yeha ... 200+ developers, 4 time zones ... try that in perl.

    3. Re:Most popular Java pattern by Enonu · · Score: 1

      There are proper ways to handle common problems when writting server-side Java applications. If everybody would simply code using these "design patterns" then understandability and maintainability would sky rocket, not to mention the fact that your solution will just plain work.

      In other words, don't roll your own when the hard work of others is out there and precisely documented for you to use. IMHO, this is part of the difference between a software-engineer and your run-of-the-mill coder.

    4. Re:Most popular Java pattern by wthynot · · Score: 1


      That's right, I'm accusing you of being a COMPUTER LANGUAGE BIGOT!

      Can't we all just get along?!?!

      As always, a great way to kick off a long and meaningful friendship.

    5. Re:Most popular Java pattern by Safiire+Arrowny · · Score: 1

      Yeah, he was saying that Java is like a buzzword, not design patterns.

    6. Re:Most popular Java pattern by Anonymous Coward · · Score: 0

      But you're old and stupid so you wouldn't understand all of these formal, educated approachs to software development.

    7. Re:Most popular Java pattern by sfjoe · · Score: 1

      Maybe I'm getting old, but at one time we just wrote systems that worked without regard to what was in fashion at the time.

      Yes, but a horse cart is far less complicated than a Porsche.

      --
      It's simple: I demand prosecution for torture.
    8. Re:Most popular Java pattern by EastCoastSurfer · · Score: 1

      C++ patterns.

      Maybe the original poster wasn't talking about patterns, but *Java* patterns. Patterns are generally supposed to be implementation independent. Personally, I would be much quicker to read a book called Distributed Architecture Patterns than J2EE patterns. In my mind all the patterns in the J2EE book should be subsets of the larger concepts presented in a Distributed Architecture book.

    9. Re:Most popular Java pattern by yintercept · · Score: 3, Insightful
      Patterns are nice to have for architects

      We just skipped the important debate about whether or not "architecture" is the right metaphor for most IT. Most IT involves systems that evolve, as such they are generally better served with a flat structure where multiple people have input on the design and direct responsibilities in regard to implementation.

      The architect metaphor is from the construction industry. In construction, the architect is pretty much elevated one step above God. The metaphor demotes everyone else to the status of code monkey. While such social patterns might be needed in a packaged software environment, I think it is better for most companies to have a flatter political hierarchy where multiple people have input on design and have their own areas of responsibility.

      Regardless, design patterns have a great deal to offer in flatter structures, as they give people greater ability to talk about design issues.

    10. Re:Most popular Java pattern by Anonymous Coward · · Score: 0

      Yes, it speaks volumes when you say your J2EE/struts/pattern driven project costs $100 million and has 200+ developers. Of course it does! Too bad you don't realize that it's a very bad thing that this technology is completely blowing your budget. That's the point! To spend that much on a system could mean nothing other than total disaster.

      And what does 100% failover have to do with cost anyway? I've delivered a dozen systems with 100% failover in the securities industry for well under $1 million each (most under $100K). Big fucking deal. It's called proper DESIGN. It sure beats rebooting the fucking java appserver twice per day to reduce memory or whenever it crashes for no good reason.

    11. Re:Most popular Java pattern by Tablizer · · Score: 1

      Maybe I'm getting old, but at one time we just wrote systems that worked without regard to what was in fashion at the time.

      Shhhhhhh! Fad-grabbing is the best jobs program we have right now. Companies pay us to rewrite programs/systems of paradigm X into paradigm X+1 because they fear that their competitors will jump past them using the latest buzzware that looks so shiney in the brochure. Rationality and jobs are not necessarily related.

      --
      Table-ized A.I.
  6. Design Patterns... by Valar · · Score: 1, Insightful

    I've never really understood the point, because 'commonly ocuring problems/projects' are, by definition, commonly occuring. People who have spent any amount of time as a junior developer or a computer science student have been handheld through these types of scenarios about 1,000 times before they actually get to design anything important on their own. Beyond that, you're never going to be able to account for the wide varieties of situations that occur in the real world with one book full of templates. Maybe someone can sell this point to me? :)

    --

    ====
    Crudely Drawn Games
    1. Re:Design Patterns... by Evil+Adrian · · Score: 4, Informative

      As an owner of the original Design Patterns bible, I can assure you, they account for an incredible variety of situations that occur in the real world.

      As it relates to OOP, it is like understanding how a car works. If you can grasp how a car works, you can generally fix any type of car.

      There are many different problems out there, but if you recognize the problem (as it fits to a particular design pattern), you can use a specific OOP design pattern as a model for a solution.

      If you spend some time learning the patterns, you save a lot of time creating a solution when a familiar problem presents itself.

      --
      evil adrian
    2. Re:Design Patterns... by joib · · Score: 2, Insightful

      Uh, I don't agree with your point. With the same logic you could say that introductory (and references for that matter) programming books are also unnecessary, since these contain stuff that "every CS undergraduate" should know. Well, you have to start somewhere and build on that. And while your memory might be perfect, mine certainly isn't, so I feel it's very helpful to have those books available.

    3. Re:Design Patterns... by Anonymous Coward · · Score: 1

      One of the great things that come out of using design patterns is that designers/coders get a common nomenclature to use when communicating. It is a great save of time to be able to refer to something as "composite pattern" instead of "you, know that piece of code that we use to manage hierarchical structures of objects and sub-objects, where some of the sub-objects can contain other sub-objects"

    4. Re:Design Patterns... by GoofyBoy · · Score: 2, Funny


      >you're never going to be able to account for the wide varieties of situations that occur in the real world with one book full of templates.

      Its a pattern, not a final soluton. Use it as a starting point/a headstart.

      >Maybe someone can sell this point to me? :)

      Number one reason I like patterns is because it gives me a warm feeling that someone already had to suffer through the same dammed problems as me.

      --
      The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
    5. Re:Design Patterns... by haystor · · Score: 2, Funny

      If these patterns are truly recurring, why can't I just do something like:

      Factory f = new Factory();

      Any good programming language should be extensible to handle frequently recurring constructs. Java does not.

      That's right, this is a LISP post. We have macros and a whole host of other things you don't, nyah nyah nyah.

      Oh yea..LISP is dead. More like, "LISP is a dead end where programmers go to never return to their original language."

      --
      t
    6. Re:Design Patterns... by Evil+Adrian · · Score: 1

      If you think you are "extending" the LISP language by building functions... ha. Call it what you want but you're doing the same thing Java programmers do, you're writing a program. The only difference is the methodology (functional vs. procedural).

      LISP isn't dead -- it's just another language. Arguing what is the "best language" is retarded, because there is only a "best language" relative to a specific problem. LISP may be great for writing AI routines, but no one sane would use it to write a cross-platform application with a GUI.

      --
      evil adrian
    7. Re:Design Patterns... by haystor · · Score: 1

      The difference between extending the language in java and LISP is that the LISP extensions are indistinguishable from the language itself.

      There are many things that just can't be done in java that require workarounds. Try using the + to add an integer to an Integer.

      Try implementing

      begin {
      } commit {
      } rollback {
      }

      to handle arbitrary code in each of the blocks. I can implement the equivalent in LISP in just a few lines. Java requires quite a bit more.

      The most successful thing about java has been its hype.

      At least with something like Perl I feel that the language attempts to meet me part way rather than declaring how everything must be done.

      --
      t
    8. Re:Design Patterns... by yintercept · · Score: 1

      Design patterns give people a greater ability to talk about programs. Unforunately, it also comes with the hype that you will be able to just create UML model with your named patterns and a working bug free programs will drop out of the sky. For the most part, the ability to talk about programs abstractly is worth the effort to learn about patterns, although pattern-speak can add nasty dimensions to corporate politics...with one click pattern-speaking and another click not.

    9. Re:Design Patterns... by btlzu2 · · Score: 0, Troll
      The most successful thing about java has been its hype.

      That's pretty much BS. Considering I have been going through a Comp Sci Master's program only knew FORTRAN and C in passing when I started, I know that Java is much much more than hype and to say otherwise is fairly ignorant. I have subsequently learned C, C++, Perl, and PHP and Java is, by far, the best bang for your buck hands down. Cross-platform is only the tip of the iceburg. Handling sockets, connecting to databases of all kinds, web development, server-side processing, etc. are elegantly solved in Java. No longer are there propriety libraries that everyone had to write in C or C++. There's a more formal ground-up OO structure in Java compared to C++. Java is absolutely not hype. Your fairly weak examples do not do much to discount from the overall benefits of Java IMHO.

      I have no knowledge of LISP, but that does NOT mean I can't argue against someone saying that Java is best at hype. That's just a dumb thing to say.

      --
      Zed's dead baby. Zed's dead.
    10. Re:Design Patterns... by haystor · · Score: 1

      Cross platform...ooh. Yea, now I can replace that big Sun box on a whim with something else. In 8 years of doing business programming, I have never (NEVER!) had to change platforms such that a rewrite would occur.

      There is a small benefit that you can run your own server on your windows box and that code should (not necessarily will) run on your server. This gives me the luxury of being able to use my IDE, Weblogic, and Lotus Notes all on my own machine. I'm going to tab over to my IDE and back real quick to see if the build is done, I'll be back in 30 minutes.

      (30 minutes and 2 alt-tabs later)

      Back. Best bang for my buck? I'll take Perl. Lets see now...More stuff than Java on more platforms running more stably divided by zero.

      Perl wins.

      Oh, and I don't give a damn about objects or patterns. They are for the weak minded who need hand holding. Blah blah blah data encapsulation. Bullshit. If I want to trash the data I damn well ought to have the power.

      It may suck to shoot yourself in the foot, but I'm not giving up my power to shoot everyone else in the foot just because I'm afraid.

      --
      t
    11. Re:Design Patterns... by E_elven · · Score: 1

      > Handling sockets, connecting to databases of all kinds, web development, server-side processing, etc. are elegantly solved in Java.

      No, they aren't. They're (elegance arguable) solved in the Java Standard Edition library.

      I hate it when people tout Java because of its libraries. Give me a few weeks (and some cash for snacks) and I'll compile you a list of C++ libraries better and more extensive.

      --
      Marxist evolution is just N generations away!
    12. Re:Design Patterns... by Anonymous Coward · · Score: 0

      Case in point: We fear what we don't understand.

    13. Re:Design Patterns... by btlzu2 · · Score: 1

      I know it's probably a subjective thing, but C++'s syntax makes me wretch. I hated C++ even though I was all excited about learning it. Java just seemed like home...less forced. This is probably an opinion thing only, but there are quite a lot less syntax kludges involved with Java than C++ IIRC & IMHO.

      I'm a big fan of C (especially, obviously, for Unix/Linux system programming) even though I don't nearly use it as much anymore, but C++ was just god-awful IMO. However, you've got to admit that C/C++ are not nearly as safe to program in as it is in Java.

      --
      Zed's dead baby. Zed's dead.
    14. Re:Design Patterns... by can_dcm · · Score: 1

      Clique, dude, clique. I'm not a spelling/grammar Nazi, but represting drunk Canadians everywhere, I was *confused* by your comment:) Visions of battling corporate mice were dancing through my head....

    15. Re:Design Patterns... by E_elven · · Score: 1

      I happen to like C++ more :)

      You say Java is safer. I ask what if I add one of the many garbage collection libraries? One -or many- of the many smart pointer libraries? How about then? :)

      --
      Marxist evolution is just N generations away!
  7. Buzzword alert!!! by Anonymous Coward · · Score: 0

    Someone has been eating too many acronyms laterly:

    J2EE Design Patterns, GoF book, JSP developer, MVC framework, UML notation, SQL strings, O/R mapping engine, EJB Container Managed Persistence.

    1. Re:Buzzword alert!!! by WormholeFiend · · Score: 1

      that's TMI, so STFU.

      "But sir, if the VP is such a VIP, shouldn't we keep his PC on the QT, 'cause if it leaks to the VC he could end up an MIA and then we'd all be put on the KP ASAP." /Good Morning Vietnam

  8. My personal favorite design pattern... by Anonymous Coward · · Score: 4, Funny

    ...is the spaghetti warehouse with a competence facade. Use it all the time.

    1. Re:My personal favorite design pattern... by Anonymous Coward · · Score: 0

      I like to compliment that pattern with the high-rate-do-nothing contractor pattern.

  9. More like antipattern by Timesprout · · Score: 4, Interesting

    I am a fan of design patterns but many of the patterns I see described in these books are workarounds for weaknesses or performance issues in the J2EE specs. In many cases a "best practice " tag is more appropriate than a design pattern.

    --
    Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
    What truth?
    There is no dupe
    1. Re:More like antipattern by Anonymous Coward · · Score: 0


      Please elaborate on the difference between "best practice" and "design pattern".

    2. Re:More like antipattern by mark_lybarger · · Score: 1

      design patterns are concerned with the design, and anti patterns are more concerned with the implementation. ok, so the two meld a little. if your design had you using J2EE CMP entity beans, you're kinda sorta stuck w/ an anitpatern.

      i see more the design patterns describing general stuff, and the anti patterns books describing lessons learned, and good (or bad) implementation practices.

  10. Design Patterns are a Shared Language by jetkust · · Score: 1

    Patterns save time and effort by supplying developers with a shared language when discussing common problems.

    Finally someone with an accurate description of what a design pattern actually is. In fact, that is ALL it is. I disagree that being able to identify patterns in your code saves time and effort though. And how does forcing patterns into your code help when, by definition, a design pattern is commonly occoring. Yes, you may have added new words to your vocabulary of programmer technobabble, but how helpful is it?

    1. Re:Design Patterns are a Shared Language by Evil+Adrian · · Score: 5, Insightful

      It's helpful in conversation, in the sense that patterns are tools. For example: it's much easier to say "singleton" than to say "make sure this class has only one instance and make sure there's a way everyone can get to it" -- just as it's easier to say "hammer" than "that thing you bang nails into things with."

      --
      evil adrian
    2. Re:Design Patterns are a Shared Language by vingilot · · Score: 2, Insightful

      I disagree that being able to identify patterns in your code saves time and effort though. And how does forcing patterns into your code help when, by definition, a design pattern is commonly occoring

      You have it backwards: Identify the pattern and your code will fit around it (no forcing). Design patterns are not about code or patterns in code-- but about architecture. And they are regonized from the problem-- the solution is the design pattern. There is not a design pattern for every problem but for the most common problems patterns represent a powerful tool.

      I have found that design patterns do relate to saved time and effort. Number one, they give clear direction as to the solution (if applied correctly). And number two, other devleopers who are familiar with patterns will understand your code quicker.

    3. Re:Design Patterns are a Shared Language by FortKnox · · Score: 1

      Its funny to explain patterns to old programmers. I usually say "You've probably used them and just not realized it". Its about 'high level' modelling, not simply algorithms.

      --
      Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
    4. Re:Design Patterns are a Shared Language by butane_bob2003 · · Score: 2, Insightful

      Patterns that are forced into code are being applied inappropriately. Patterns tend to fall into place where necessary, not needing to be sought out or hammered into shape. If you have a very good grasp on the applicability and shortcomings of known patterns and combinations of patterns, you will benefit from their use. Patterns stretch most developers into a realm that is more abstract than they are used too, which is why many developers misuse them. Novices introduced to patterns will try to apply them to everything, and end up wasting a lot of time thinking about how to apply them. If you are a good 00 programmer, the patterns will find you without much extra effort on your part.

      --


      TallGreen CMS hosting
    5. Re:Design Patterns are a Shared Language by bluGill · · Score: 1

      Well yes and no. A design pattern is commonly occuring in general industry. That doesn't mean that your particular branch will use it. So not only do you gain a simple language to talk about what you are doing, but you also get insight into things you could/should be doing, but instead are doing a much harder way not realizing it.

      Recognizing patterns also helps in deisgn. You know you need to do something. By having a list of patterns you turn to the list to make sure you pick the right one, instead of one similear that isn't quite the same, and doesn't fit quite right but you can force it to work.

      Of course once you see patterns you've never seen nor though of, you might be tempted to use them where they don't make sense. Normally not a problem.

  11. Participating in a focus group on design patterns, by Anonymous Coward · · Score: 3, Insightful
    I may be able to offer some perspectives.

    The basic concept behind a design pattern is to reduce common tasks to a set of repeatable and clearly-defined models. These models are:

    • Simple to implement
    • Either complete in themselves or modular
    • Easily repeatable

    Most businesses find themselves using one of three different design patterns. Larger businesses tend to choose one that is more suitable for dealing with a larger amount of business, whereas smaller businesses may find a more cost- and time-effective solution in a cheaper pattern.

    I haven't read this book, but it's likely it'll touch on these and other design patterns. As always, it comes down to choosing the pattern you're most comfortable with.

  12. more reviews of this book by Anonymous Coward · · Score: 3, Informative

    VeryGeekyBooks has more reviews of this book.

    1. Re:more reviews of this book by Anonymous Coward · · Score: 0

      All linked to affiliate sites, with referral IDs attached. Good job, spammer.

    2. Re:more reviews of this book by Anonymous Coward · · Score: 0

      no, only the ads are linked to referrals, like the ads on any other web site. All the external book reviews are regular links.

  13. Definitions. by ninejaguar · · Score: 1
    A pattern involves three components: first, a description of a generalized recurring problem; second, an abstract solution that is generally accepted; and third, a name for the sake of convenience.

    What's the difference between a Design Pattern and a template?

    = 9J =

    1. Re:Definitions. by FerretFrottage · · Score: 1

      Actually there is a design pattern called the "template pattern"

      --
      "Look Lois, the two symbols of the Republican Party: an elephant, and a fat white guy who is threatened by change."
    2. Re:Definitions. by 2nd+Post! · · Score: 1

      In common parlance, a template is a pattern and a pattern is a template.

      When you want to make a dress, you don't buy a template, you buy a pattern.
      When you want spray paint letters onto a sign, you use a stencil, not a template.
      When you're carving letters into stone, you use a template, not a pattern.

      It's all about relevant language. If someone else had written a salient article, perhaps we'd be talking about design templates, and pattern template, instead of design patterns and the template pattern.

      Regardless, the point is still the same: Design patterns provides a vocabulary in which people can talk about problems and solutions.

      --

      GPL Deconstructed
    3. Re:Definitions. by lysander · · Score: 2, Informative
      What's the difference between a Design Pattern and a template?
      A template you fill in. This assumes that someone has already solved your exact problem, and you just need to add the details specific to this particular incarnation of the problem.

      Design patterns are programming concepts that you can assemble to solve your problem. They are reusable in the sense that the problems that patterns solve come up often enough that knowing when and how to use them becomes important.

      Design patterns also encapsulate nicely the best ways to look at some problems. Using patterns does not imply that there is only one way of solving a problem. Several patterns provide similiar functionality and yield different trade-offs, such as future customizability, efficiency, straightforwardness to implement, and opportunity for code reuse. Knowledge of patterns can help when designing solutions and analyzing alternatives, and they can also provide a good road map during implementation.

      --
      GET YOUR WEAPONS READY! --DR.LIGHT
  14. Re:Oh, what a nice pattern by Karamchand · · Score: 1

    I don't mind being modded down, but I mind if all you techies think the form, the presentation doesn't matter - it does. A text should be readable as easy as possible. Therefor it is not advisable to set it all italic. Fewer people might read it, fewer people might get the message. And usually that's not what you as a writer want.
    Regards

  15. More J2EE patterns by ^Case^ · · Score: 4, Informative


    Core J2EE Patterns is another book on the subject. You can even find many (all?) of the patterns from the book online.

    I've found a lot of these patterns to be useful in other domains (PHP webapps) as well.

  16. Is the Design Patterns book insane ? by andy666 · · Score: 1

    Is it just me or do others find this book to be unreadable and crazy ?

    1. Re:Is the Design Patterns book insane ? by NickFitz · · Score: 1

      Just you.

      --
      Using HTML in email is like putting sound effects on your phone calls. Just say <strong>no</strong>.
  17. Too cold a definition by Anonymous Coward · · Score: 1, Informative

    Design Patterns were inspired by the terrific book 'A Pattern Language' by Christopher Alexander.

    But, in this book, a pattern is not -just- a commonly accepted solution. It's a solution that's really good, really works incredibly well, and feels like a fundamental thing. It's a solution whose insight leaves a lasting impression on you.

    This is where the software design patterns people rather missed the point, and the razzing they get from older engineers is well-deserved.

    1. Re:Too cold a definition by Anonymous Coward · · Score: 0

      maybe they should read the other two books in the series
      "The Oregon Experiment" and
      "A Timeless Way of Building" both by Christopher Alexander.
      They might even stop calling themselves architects once they truely understand.

  18. "IForone" pattern by Begemot · · Score: 1

    I, for one, welcome our new Singleton(); overlord (sorry couldn't resist).

    1. Re:"IForone" pattern by Mindwarp · · Score: 3, Funny

      I, for one, welcome our new Singleton(); overlord (sorry couldn't resist).

      That should read "I, for one, welcome our Singleton.getInstance() overlord"

      Sorry, couldn't resist ;-)

      --
      The gift of death metal does not smile on the good looking.
    2. Re:"IForone" pattern by butane_bob2003 · · Score: 3, Funny

      Any one notice that our 'new' Singleton overlord is the exact same one as the old one?

      --


      TallGreen CMS hosting
    3. Re:"IForone" pattern by DarthTaco · · Score: 1

      Any one notice that our 'new' Singleton overlord is the exact same one as the old one?
      Now that was funny.

    4. Re:"IForone" pattern by Kingpin · · Score: 1


      ISingleton.getInstance().welcome("overlord"); :)

      --
      Unable to read configuration file '/bigassraid/htdig//conf/14229.conf'
      Geocrawler error message.
  19. Re:Oh, what a nice pattern by October_30th · · Score: 1
    That actually reminds me of a good point my MD friend made a while ago.

    He's was involved in an MRI R&D project and was frustrated by the techies/engineers/scientists who insisted on using obscure slang without bothering to translate it. You know, the classical RTFM attitude of an elitist geek.

    Over here they teach the MDs to deal with young and old people, people with low/high IQ, people with good/bad literacy and so on. In short, they teach social skills. In my mind, this should be made compulsory in the engineering/science degrees as well.

    As I say to my students: if you can't communicate an idea in quantum mechanics to your grandma, you have not really understood the physics.

    --
    The owls are not what they seem
  20. Didn't we just have such a review? by mcbevin · · Score: 5, Interesting

    I remember commenting on some other topic regarding J2EE design patterns recently.

    Like I sort of said that time, the design patterns are mostly just workarounds for a bad system. My advice is 'use JDO' and avoid all these problems (this is coming from someone working on both a JDO and a J2EE system right now).

    I do in fact have one such EJB design patterns book, and its crazy the lengths they go to to make a broken system work ....

    - Its too costly to make calls to an EJB's individual get methods - make a value object for each EJB!

    - Don't like making all these extra objects, and coping with the extra maintenance required, and writing all the methods to transfer values between the EJBs and these objects? Transfer the information using a hashmap!

    - Don't like the loss of all the advantages of using OO programming languages and entity beans instead of SQL which comes from passing everything with hashmaps? etc etc

    Enough to make any experienced _object oriented_ programmer pull their hair out. Of course, if you prefer using the buzzwords of 'EJB design patterns' to the practicality of JDO then go ahead, code an EJB application - enjoy developing in an environment where the deployment required to test any changes is 5 minutes plus for any decent sized EJB project, where your $10,000s EJB server can't work out how to handle basic relations in the right order, and where you have to code half of your queries in SQL anyway (i.e. see the 'Data Access Command beans' pattern which the book no doubt has) as the system is so slow and not powerful enough.

    1. Re:Didn't we just have such a review? by balbeir · · Score: 1, Insightful

      Amen to that. J2EE itself suffers from the "Golden Hammer" antipattern. There is a certain class of problems that J2EE is good for: e.g. as a backend for a web application. For a lot of problems in the real world there is an impedance mismatch that makes any competent developer pull out their hair. No threads, no direct access to files etc... Something that is simple without J2EE suddenly becomes a balancing act on a tightrope with both hands tied to your back when you're forced to do it in the constrained environment that J2EE provides you. Unfortunately the whole thing is so hyped that a lot of "architects" won't even consider solving a problem without J2EE.

    2. Re:Didn't we just have such a review? by FerretFrottage · · Score: 1

      I think you are right on here. EJBs are really a component model, not an object one. As such components don't map real well to persistence. That is where implemtations such as JDO come in--they fill that need (weakness) in the current EJB model. There is talk of CMP beans implementations that support JDO (ouch metadata overload) or even JDO replacing entity EJBs someday. Oh, life as an object will be interesting (well if it wants to save itself)

      --
      "Look Lois, the two symbols of the Republican Party: an elephant, and a fat white guy who is threatened by change."
  21. Here comes the flame bait, but ... by jemele · · Score: 1

    Design patterns can be useful. The demonstrate good design in generally language neutral terms. They are useful teaching devices and solidly formalise a lot of things a lot of people having been saying in a lot of communities for a long time.

    But they are not the end-all-be-all-panacea that some developers (and managers) imagine them to be. I have witnessed the following more than once, and it scares the hell out of me:

    Oh, the proxy manager pool pattern in my framework does not have a helper. Perhaps a composite visitor pattern will suffice ...

    I try to run the fsck away when I hear such atrocities (that is a euphemism, kids ;).

    What is more, one day bored, I wrote a small script to go through the tree, examine all class declarations.

    The design pattern fanatics had a mean class name length of 73 ... not 7.3, or 13 ... 73 ...

    They were also using delphi, so no typedef for them ;)

    Long story short, good teaching tool, awesome way to watch the stupid and uninformed create a tangled web of complexity to hang themselves in ...

    Naturally, Your Mileage May Vary :) (tm)
    joshua

  22. Design Patterns Explained by dilute · · Score: 1

    If you want to know about design patterns (and you SHOULD), the Gang of Four book is the classic. However, I have found another book (Design Patterns Explained, by Shalloway) that really lays it out, explaining how to evaluate which pattern is right (or best) for a particular task or project. Read that book first.

  23. And don't forget... by Anonymous Coward · · Score: 0

    ... to use the new cover page on the TPS reports...

  24. Designpattern today, antipattern tomorrow by PingoSvin · · Score: 0, Flamebait

    A book which doesn't mention alternatives to entitybeans and raw sql sounds quite outdated.
    The story of cmp/ejb is really the tale of the emperor's new clothes. Three years ago any critique voiced against this new wonder tech. was labeled as uneducated drivel. But the truth was that anyone(ok not you) forced to work in this setting, was demonstrating terrible productivity.
    As anyone reading theserverside.com will acknowledge, the emperor has now officially been declared naked.
    Now it's time for the trial. Let's have a book examining how and why so many clever and bright people could be fooled so badly.

  25. Re:Design Patterns For Beginners by butane_bob2003 · · Score: 1

    Sure, things can be refactored into a common library that can be used for things that won't need to change. But this is usually best done *after* it is determined a component is re-usable. This determination is best made after a component is reused a few times, not before it has ever been used at all.

    Every one has written an XML toolkit, File toolkit, JSP toolkit, Swing toolkit, etc.. The Java SDK is a 'tookit' itself. This does not eliminate the need for design patterns. In reality, software is designed from the top down, where the top layer is the user/client interface(s). (where the client can be human,monkey,machine,other software,etc..). As the layers get lower and lower, they (should) become less volatile. Good bottom up designs are made better (more flexible,expandable) by design patterns.

    Removing dependancies on the 'toolkits' can be extremely difficult without the simplest design patterns. Dependencies between layers of applications are to be avoided for obvious reasons.

    Design patterns can't be avoided in good object oriented design. They are not a product of some company or focus group deciding developers need a new tool, they are natural occurences that have been observed and recorded during the development cycle that people have found useful and often necessary.

    --


    TallGreen CMS hosting
  26. Design Patterns...Who's on "First"? by Anonymous Coward · · Score: 0

    Soo's FORTH. I don't see anyone crowing about that

    Besides LISP had it's chance...and it's share of hype as well. BTW I use Smalltalk, so their, pffft!.

  27. How about web Services... by timjdot · · Score: 1

    ...tell me how you really feel! If you think the ideas of an object system (entity beans) over a constant barrage into an RDBMS are bad, then you must really be pissing your pants now that Web Services is the new rage. Talk about one more re-hash for distributed computing. "Let's think of the slowest possible distributed computing infrastructure and promote that".
    Maybe one can define all the patterns on a few basic patterns -- caller, callee, data store. In addition to GoF, "The Pattern Almanac" was the best book I found because it lists all the names of these patterns as used in various industries. As skilled programmers who know how computers work we all have done most of these before or could do them in a few weeks if needed. Personally, I think using pattern names is useful as it gives one more level of composition abstraction - something between talking about a module and a class perhaps.

    --
    Expect Freedom.
  28. Joke Pattern with Humor Facade by deadlinegrunt · · Score: 1

    you'll see the four circles around the exit. lower traffic, and possibly just straight exit and entrance ramps w/out the loops.

    On older freeway systems you got performance increases too from loop unrolling although todays freeway systems that is less and less of a concern because of new aggressive optimizing architects and civil engineer caching.

    My comment has nothing to do with design patterns by the way - it's an implementation artifact of humor.

    --
    BSD is designed. Linux is grown. C++ libs
  29. In other words by LPetrazickis · · Score: 1

    "But, sir, if the Vice President is such a Very Important Person, shouldn't we keep his Personal Computer on the Quick Time, 'cause if it leaks to the Venture Capitalists he could end up Missing in Action and we'd all be sent to maintain www.goatse.kp (North Korea)."

    You make a strong point.

    --
    Is this a sigs-optional kind of place? 'Cause I am totally down with that if you know what I mean.
  30. Simple Definition - Simple Thoughts by bossvader · · Score: 1

    Patterns are a common strategy/idiom for solving a common class of problems. Poorly applied patterns, indiscriminently applied or poorly-understood patterns will make things worse. Anti-Patterns are as important as normal patterns. (See above) A nice tool with pattern support/generation (Together ControlCenter) can help with implementation and understanding.

  31. no mention of Alexander? by goon · · Score: 1

    when the enevitable book,discussion, etc on patterns and their use in software I remind myself of Christopher Alexander , Austrian born, Cambridge educated maths and architecture graduate.

    One aspect of Alexanders work often overlooked, is that we should be making up your own patterns. Instead we look to references as cook books rather than as building blocks.


    --
    peterrenshaw ~ Another Scrappy Startup