locked
how many design patterns used in one project or one architecture RRS feed

  • Question

  • User534182787 posted

    may i know that for every functionality we have to use one patterns so in project architecture we have to use many design patterns is it correct
     
    to design architecture how many design patterns are used
     
    those are one or many

    Wednesday, August 14, 2013 1:22 AM

All replies

  • User1109032460 posted

    You do not have to use one pattern for every piece of functionality. In fact, many pieces of functionality don't use patterns at all, and some pieces will use multiple patterns.

    What is true is that, given a particular problem and context, there is likely to be a recognised pattern that helps solve that problem in that context. And it is also true that given a complex problem - and most larger-scale software will have complex problems - we use multiple patterns in conjunction to solve the complex problem.

    No-one can possibly answer the question "to design architecture, how many patterns are used?"

    The reason being that every architecture, by definition, is targeted towards solving a different set of business requirements. Therefore, every architecture will, ultimately, use its own set of patterns.

    You can safely assume that any reasonable system will use multiple patterns. However, without understanding what the problem and requirements are, you cannot state what the combination of patterns will be.

    So the answer to your question is the consultants' favourite: "it depends".

    Don't take this the wrong way, but the very nature of your question reveals that you don't really know anything about design patterns. This is perfectly fine and normal when someone is starting out investigating patterns, so don't worry. I would therefore strongly advise you to read the book "Head First Design Patterns" before you go any further. This is a superb introduction to design patterns, and will really help you to understand the "why" of design patterns, and not just the "what".

    One cautionary word of warning. There are a lot of articles on the likes of CodeProject that attempt to explain design patterns. Many of them are very, very wrong. If you stick with the Head First book in the first instance, and truly understand it, then you will be able to look at the samples on the web and judge them for yourself.

    Wednesday, August 14, 2013 7:42 AM
  • User-488622176 posted

    There is absolutely no relation between good architecture and patterns, so there is no relation between a project architecture and patterns. An architecture (software, application landscape, business, building,...) can consist one or more patterns, and likely will, but this is not required.

    A pattern can be seen as a concept solution that shows how to solve problem X (based upon requirements), by providing a structured approach / prescription on how to do this, based upon previous knowledge & experience that has proven to lead to valuable results. This implies patterns do solve problems (as long as you use the right pattern for the right problem, some are not that simple). They allow you to learn and gain experience in how specific (sometimes complex) problems are solved by experts. However, if you gain yourself a lot of experience, you might very well either come to the conclusion you rarely need patterns, or come to the conclusion some of your solution recepies are in fact existing patterns.

    Use patterns is you find them usefull and if they help you. However, do take the efford to get to kwow them, understand them and learn them. Their knowledge will certainly benefit you in the upcoming years. Start with design patterns ("head first design patterns" or the book by gamme et al (design patterns) are a good place to start). Afterwards, you have enterprise application patterns (ex: the work by Martin Fowler), ...

    Monday, August 19, 2013 3:21 AM