10 Replies Latest reply: May 20, 2010 1:41 AM by jwenting RSS

    Is it ever better to avoid design patterns?

    843853
      I'm fairly new to working with design patterns and I can understand how using them gives benefits. But at some points I begin to wonder if things are getting over-engineered. I've not done any commercial Java projects so I'm not sure if there are trade-offs from the 'perfect' design to project deadlines which normally affects most projects I've worked on in the past.
      The current pattern I was looking at was DAO's ( http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html ), where there are 4 classes needed to persist data! I can understand why it's done that way, but the amount of extra coding I would have thought would outweigh the perceived benefits that it would give.
      The idea that the coding protects from changes is valid - but if your writing a commercial application you are usually given a configuration to work with and a deadline to write it for. Niceties like future proofing are like diamond encrusted hub caps when your working on a second hand car. You could also be cynical and say that designing this flexibility into the system is doing the salesman out of extra cash when the requirement changes ( worked for consultancies for to long ).
      It's a bit like third normal form on relational databases - ideal, but real systems usually have some tweaks to make the system work better. ( I won't go into how I've always thought foreign keys were a waste of time at this point ).
      Interested to hear other peoples ideas on this ( withdraws to nuclear bunker and waits for a barrage of hate mail )
        • 1. Re: Is it ever better to avoid design patterns?
          jschellSomeoneStoleMyAlias
          You use a design pattern because you have a design that suggests a pattern.
          If you have a design that doesn't suggest a pattern then you don't use a pattern.

          And I seriously doubt that it is going to be faster for you to implement the first case without using a pattern, without suggesting that the design is flawed.

          Per you example of DAO, there are four patterns there not one. If you need four patterns then you need them. If you only need one then that is what you use. And Abstract Factory is seldom needed.
          • 2. Re: Is it ever better to avoid design patterns?
            800387
            NigelRen wrote:
            I'm fairly new to working with design patterns and I can understand how using them gives benefits. But at some points I begin to wonder if things are getting over-engineered. I've not done any commercial Java projects so I'm not sure if there are trade-offs from the 'perfect' design to project deadlines which normally affects most projects I've worked on in the past.
            Yes, all software (and indeed life in general) involves trade-offs. "Experience" is choosing the right ones.
            The current pattern I was looking at was DAO's ( http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html ), where there are 4 classes needed to persist data! I can understand why it's done that way, but the amount of extra coding I would have thought would outweigh the perceived benefits that it would give.
            As JSchell indicated, there are other patterns displayed there in addition to the DAO. Generally, a DAO is an excellent pattern to use. Relational thinking (if you are writing vanilla JDBC) is very different than object-oriented thinking. So, to me, it is "natural" to segregate the former in a separate object. Further, you really should be able to write your domain classes without any knowledge whatsoever of how they will be persisted. You should be able to test the integration of those domain objects with persistence objects (e.g., DAO's) using mocking frameworks. Segregating persistence from domain is normally worth the effort. However, typically, I have a single DAO class handling the persistence of a given object or graph of objects. Yes, if you are in that rare case where an object will be persisted across multiple RDBMS vendors, then by all means use an AbstractFactory as well.
            The idea that the coding protects from changes is valid - but if your writing a commercial application you are usually given a configuration to work with and a deadline to write it for. Niceties like future proofing are like diamond encrusted hub caps when your working on a second hand car. You could also be cynical and say that designing this flexibility into the system is doing the salesman out of extra cash when the requirement changes ( worked for consultancies for to long ).
            Until you have to go back and maintain that second-hand car. Granted, the analogy is flawed. Diamond hubcaps are still superfluous. Generally, a better design will lead to easier maintenance. There are, of course, a host of other factors that aid maintenance, the most prominent being documentation and well organized code. These, too, take additional time. However, I would normally consider the extra effort worth it.
            It's a bit like third normal form on relational databases - ideal, but real systems usually have some tweaks to make the system work better. ( I won't go into how I've always thought foreign keys were a waste of time at this point ).
            Third normal form should be your default in a data model. I am not saying take it to Boyce-Codd or fifth normal form, but third normal should be your goal. In a pinch or under a deadline, yes, you can have a denormalized table or two. But that should not be your starting point.
            Interested to hear other peoples ideas on this ( withdraws to nuclear bunker and waits for a barrage of hate mail )
            No nukes en route.

            - Saish
            • 3. Re: Is it ever better to avoid design patterns?
              jwenting
              yes, it is often better to avoid patterns (or at least specific patterns).
              This is especially true for the people who come here and ask questions like "what pattern should I use to implement this", "want to make app using X pattern, plz suggest", etc. etc.

              Using a pattern for the pattern's sake is never the right thing to do (unless one is writing a tutorial on that particular pattern of course, in which case a contrived example might serve the purpose of clearly showing how the pattern is implemented without confusing the topic).

              In any other scenario, the patterns to be used should suggest themselves from the technical (or even functional) design, and flow freely from the hands of the programmers rather than requiring them to jump through hoops in order to force them onto the design.
              • 4. Re: Is it ever better to avoid design patterns?
                843853
                jwenting wrote:
                In any other scenario, the patterns to be used should suggest themselves from the technical (or even functional) design, and flow freely from the hands of the programmers rather than requiring them to jump through hoops in order to force them onto the design.
                I agree. The fundamental win for the software engineering community with the Gang of 4 design patterns (or any other well-published design patterns) wasn't that they were revolutionary ways of solving something. It was that they provided a common terminology to discuss some building blocks of software architecture. As a result, if you find yourself mashing a design pattern into an architecture, you've probably lost that benefit (since your use of them won't fit into others' understanding of what the DP means) and so should not have used the design pattern at all (by name, anyway).
                • 5. Re: Is it ever better to avoid design patterns?
                  843853
                  Thanks for the replies - it has given me a better standpoint to look at how design patterns should be used.
                  I had it in my mind that patterns were almost being pushed as an alternative to normal OO design, being more a set of jigsaw pieces what fitted together to make the perfect design. Where as I think I should be looking at it in the mindset of these are things to be aware of and if the piece fits then use it. It does mean though ( as many things ) you need to understand the patterns to be able to get the best use of them. No trying to plug things together until the pieces weave together nicely by accident.
                  I suppose giving people a common set of patterns to allow easy communication of the design helps. It reduces the amount of new information people have to absorb for a new design.
                  What would be a good resource for learning the design patterns, I've found a few so far ( http://www.oodesign.com/ being one ), but it would be useful to see some other suggestions.
                  • 6. good resource for learning the design patterns
                    782681
                    NigelRen wrote:
                    ...What would be a good resource for learning the design patterns, I've found a few so far ( http://www.oodesign.com/ being one ), but it would be useful to see some other suggestions.
                    I recommend [reading threads|http://forums.sun.com/thread.jspa?messageID=10857286#10857286|explanation] in this forum. +"Funny that simply reading how guys share and discuss practical problems brought me further than I could ever get by studying books and tutorials..."+
                    • 7. Re: Is it ever better to avoid design patterns?
                      843853
                      NigelRen wrote:
                      I had it in my mind that patterns were almost being pushed as an alternative to normal OO design, being more a set of jigsaw pieces what fitted together to make the perfect design.
                      I'm not sure I know what you mean by "normal" OO design. They mostly follow object oriented design principles.
                      Where as I think I should be looking at it in the mindset of these are things to be aware of and if the piece fits then use it.
                      They're great for inspiration too. But then it's good to know what's available.
                      I suppose giving people a common set of patterns to allow easy communication of the design helps. It reduces the amount of new information people have to absorb for a new design.
                      That's a pretty huge barrier removed from bringing somebody up to speed on an architecture. It also helps mitigate the risk of institutional knowledge walking out the door with your chief architect.
                      What would be a good resource for learning the design patterns, I've found a few so far ( http://www.oodesign.com/ being one ), but it would be useful to see some other suggestions.
                      [The Go4 book|http://en.wikipedia.org/wiki/Design_Patterns] is a good reference.
                      • 8. Re: Is it ever better to avoid design patterns?
                        800387
                        I you enjoy learning by reading code examples, then Holub's book on patterns is outstanding. Or for some nice free stuff http://www.objectmentor.com/resources/publishedArticles.html.

                        - Saish
                        • 9. Re: Is it ever better to avoid design patterns?
                          jduprez
                          Where as I think I should be looking at it in the mindset of these are things to be aware of and if the piece fits then use it.
                          They're great for inspiration too. But then it's good to know what's available.
                          What would be a good resource for learning the design patterns, I've found a few so far ( http://www.oodesign.com/ being one ), but it would be useful to see some other suggestions.
                          [The Go4 book|http://en.wikipedia.org/wiki/Design_Patterns] is a good reference.
                          In terms of mindset and terminology, Robert C Martin (aka uncle Bob) published a series or articles on OO design principles that inpired me.
                          A lazy search turned the following links:
                          [http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod]
                          [http://www.objectmentor.com/resources/publishedArticles.html] (hey there are a damn lot of new ones since I've last been there!)
                          • 10. Re: Is it ever better to avoid design patterns?
                            jwenting
                            endasil wrote:
                            NigelRen wrote:
                            I had it in my mind that patterns were almost being pushed as an alternative to normal OO design, being more a set of jigsaw pieces what fitted together to make the perfect design.
                            I'm not sure I know what you mean by "normal" OO design. They mostly follow object oriented design principles.
                            I think what he means is the practice of assuming that deciding to use a specific pattern can replace the entire design phase of the application, something we see a lot in threads here (usually by schoolkids, not professionals).
                            I suppose giving people a common set of patterns to allow easy communication of the design helps. It reduces the amount of new information people have to absorb for a new design.
                            That's a pretty huge barrier removed from bringing somebody up to speed on an architecture. It also helps mitigate the risk of institutional knowledge walking out the door with your chief architect.
                            There's more than one chief architect I'd have loved to see gone, knowledge and all, but those are stories for the campfire :)
                            What would be a good resource for learning the design patterns, I've found a few so far ( http://www.oodesign.com/ being one ), but it would be useful to see some other suggestions.
                            [The Go4 book|http://en.wikipedia.org/wiki/Design_Patterns] is a good reference.
                            Reference, yes. As a tutorial I'd go with Head First Design Patterns and Head First Object Oriented Software Development.
                            Between them they explain the most useful patterns (a good subset of the GoF patterns) as well as trying to give an idea of practical applications for them.