Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Books Media Book Reviews

J2EE Design Patterns 130

Posted by timothy 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.
This discussion has been archived. No new comments can be posted.

J2EE Design Patterns More

J2EE Design Patterns

Comments Filter:

  • Here's a design pattern: (Score:3, Funny)

    by deadlinegrunt ( 520160 ) on Wednesday November 26, 2003 @12:20PM (#7570142) Homepage Journal
    I call it the tag delimeter pattern.
  • 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...
    • 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.
      • 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.
        • I would argue that "freeway exit" represents an abstract object, of which are derived different concrete types... ;-)
        • 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.

        • 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 i

      • 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.
    • 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

    • Re:Still Not Real Clear on Design Patterns... (Score:5, Insightful)

      by j3110 ( 193209 ) <samterrell @ g m a i l.com> on Wednesday November 26, 2003 @12:30PM (#7570273) Homepage
      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.
      • 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 real

    • Re:Still Not Real Clear on Design Patterns... (Score:4, Informative)

      by Space cowboy ( 13680 ) on Wednesday November 26, 2003 @12:32PM (#7570286) Journal
      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.
    • 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.
    • Software design patterns [patternlanguage.com] are an offshoot of Christopher Alexander's [patternlanguage.com] architectural patterns [patternlanguage.com] as described in his book: A Pattern Language [eraline.com]. (E.g., reviewed here [utsa.edu] and here [usyd.edu.au].)

      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

    • 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 tw
      • 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.
        • 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.
          • 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.
            • Isn't that like "extending" the class?

              He already said not:

              adding functionality by composition rather than inheritance
              • 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.

                • 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;
                  }
                  }

    • 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 [google.ca]

  • Another useful patterns book (Score:3, Informative)

    by Space cowboy ( 13680 ) on Wednesday November 26, 2003 @12:21PM (#7570160) Journal
    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

  • hear hear (Score:3, Interesting)

    by m0smithslash ( 641068 ) on Wednesday November 26, 2003 @12:21PM (#7570161) Homepage Journal
    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.

  • Most popular Java pattern (Score:3, Funny)

    by Anonymous Coward on Wednesday November 26, 2003 @12:22PM (#7570165)
    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!

    • 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 y

      • 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.
      • Yeah, he was saying that Java is like a buzzword, not design patterns.

      • 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.

      • Re:Most popular Java pattern (Score:4, Insightful)

        by yintercept ( 517362 ) on Wednesday November 26, 2003 @03:45PM (#7572333) Homepage Journal
        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.

    • 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.
    • 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.

    • 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.

  • Design Patterns... (Score:2, Insightful)

    by Valar ( 167606 )
    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. Mayb

    • Re:Design Patterns... (Score:5, Informative)

      by Evil Adrian ( 253301 ) on Wednesday November 26, 2003 @12:29PM (#7570258) Homepage
      As an owner of the original Design Patterns [amazon.com] 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.
      • 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."
        • 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-platfo
          • 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
            • 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 develo
              • 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 qui
              • > 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.
                • 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/
                  • 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? :)

    • Re:Design Patterns... (Score:3, Insightful)

      by joib ( 70841 )
      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.

    • Re:Design Patterns... (Score:1)

      by Anonymous Coward
      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"

    • >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.
    • 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.
      • 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....

  • My personal favorite design pattern... (Score:4, Funny)

    by Anonymous Coward on Wednesday November 26, 2003 @12:26PM (#7570229)
    ...is the spaghetti warehouse with a competence facade. Use it all the time.

  • More like antipattern (Score:5, Interesting)

    by Timesprout ( 579035 ) on Wednesday November 26, 2003 @12:30PM (#7570267)
    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.
    • 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.
  • 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

    • Re:Design Patterns are a Shared Language (Score:5, Insightful)

      by Evil Adrian ( 253301 ) on Wednesday November 26, 2003 @12:42PM (#7570410) Homepage
      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."
    • 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 th
    • 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

    • 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

  • Participating in a focus group on design patterns, (Score:3, Insightful)

    by Anonymous Coward on Wednesday November 26, 2003 @12:38PM (#7570358)
    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.

  • more reviews of this book (Score:3, Informative)

    by Anonymous Coward on Wednesday November 26, 2003 @12:42PM (#7570409)
    VeryGeekyBooks [verygeekybooks.com] has more reviews of this 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.

    What's the difference between a Design Pattern and a template [reference.com]?

    = 9J =

    • Actually there is a design pattern called the "template pattern"
    • 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.

      Rega

    • Re:Definitions. (Score:2, Informative)

      by lysander ( 31017 )

      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 encapsu

  • More J2EE patterns (Score:4, Informative)

    by ^Case^ ( 135042 ) on Wednesday November 26, 2003 @12:50PM (#7570499)
    [sun.com]
    Core J2EE Patterns is another book on the subject. You can even find many (all?) of the patterns from the book online [sun.com].

    I've found a lot of these patterns to be useful in other domains (PHP webapps) as well.
  • Is it just me or do others find this book to be unreadable and crazy ?

  • Too cold a definition (Score:1, Informative)

    by Anonymous Coward
    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.
  • I, for one, welcome our new Singleton(); overlord (sorry couldn't resist).

  • Didn't we just have such a review? (Score:5, Interesting)

    by mcbevin ( 450303 ) on Wednesday November 26, 2003 @12:56PM (#7570567) Homepage
    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.

    • 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 constraine
    • 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)
  • 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
  • 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.
  • ...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
  • 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.

  • when the enevitable book,discussion, etc on patterns and their use in software I remind myself of Christopher Alexander [utsa.edu] , Austrian born, Cambridge [cam.ac.uk] 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 [patternlanguage.com].

Slashdot Top Deals

"The vast majority of successful major crimes against property are perpetrated by individuals abusing positions of trust." -- Lawrence Dalzell

Close