This discussion is archived
12 Replies Latest reply: Jul 12, 2006 4:42 AM by 807569 RSS

Design Patterns

807569 Newbie
Currently Being Moderated
Hello folks,

wow - it's been a while since my last post. The last few times I hade some sort of syntax problem. This time I have a completly different question as I need an advise on programming in general.
I am currently studying CS at an University of M´┐Żnster, Germany and we are doing a software project. We are supposed to write software for an PDA during a period of one semester. This means that the project will not be too complicated and not too complex. My question to you is this: Should we try to use Design Patterns as described in the popular book "Design Patterns" (1995, Addison Wesley) or do you think that this kind of "advanced" programming should only be used in big projects?

Thank you very much for answering.

Martin
  • 1. Re: Design Patterns
    807569 Newbie
    Currently Being Moderated
    Use design patterns. USE DESIGN PATTERNS. USE DESIGN PATTERNS.
  • 2. Re: Design Patterns
    807569 Newbie
    Currently Being Moderated
    When is a project considered "big"? Actually I don't think size is all that matters in this case.
  • 3. Re: Design Patterns
    807569 Newbie
    Currently Being Moderated
    Use them. Dont over-use them :) Doesn't matter if the project is big or small. Though I guess that in large projects, the chances of using one or more design patterns increases due the obvious volume of the application.
  • 4. Re: Design Patterns
    800322 Newbie
    Currently Being Moderated
    I think you should use them - simply because it's a matter of good software design, and not of some development process. Sometimes you can't even avoid using them. If you need a singleton, then you need a singleton. You could as well be asking whether you should leave "loose coupling" to big software projects.

    But use them where necessary, not simply because they exist.

    Patterns will help you solve some design questions and improve the maintainability of your code. Most important I think would be MVC, the separation of data, view and controller. You definitely have to follow that, you you might code yourself into a corner.
  • 5. Re: Design Patterns
    798906 Newbie
    Currently Being Moderated
    But use them where necessary, not simply because they
    exist.
    I agree
  • 6. Re: Design Patterns
    807569 Newbie
    Currently Being Moderated
    Wow. Thanks for your quick answers. I don't think I have the time to go deep into all of the design patterns. Do you think it is a good idea to try to get a quick overview on what exists and than look at certain patterns more closely? Do you think that there is something like a top 3 of pattens? I mean are some patterns used in almost every project? Which do you think are those?On which should I concentrate and which patterns should I study first?
    So many questions....
  • 7. Re: Design Patterns
    800322 Newbie
    Currently Being Moderated
    Wow. Thanks for your quick answers. I don't think I
    have the time to go deep into all of the design
    patterns. Do you think it is a good idea to try to
    get a quick overview on what exists and than look at
    certain patterns more closely? Do you think that
    there is something like a top 3 of pattens?
    Honestly: do you understand what design patterns are?

    Is there a top 3 of vehicles?

    Which patterns you need depends on what you want to do.
    I mean
    are some patterns used in almost every project? Which
    do you think are those?
    MVC, Facade maybe, Singleton probably because it's heavily overused...
    On which should I concentrate
    and which patterns should I study first?
    So many questions....
    The GoF book isn't that thick.. :) And each pattern comes with a description about what to use a particular pattern for.
  • 8. Re: Design Patterns
    807569 Newbie
    Currently Being Moderated
    In my experience, you can't begin using design patterns unless you have seen them in action somewhere. Most design patterns are nothing but a common-sense solution to an existing problem.

    I would suggest you keep them aside and design your application as you would do normally. Then take a close look at your design. Maybe your have five components talking to each other in dis-orderly fashion. Time to look at Mediator pattern. Maybe you are constructing objects of a certain Manager/Service class repeatedly. Time to look at Factory patterns. If you are designing a web-app, then MVC is a de-facto pattern. Of course, doesn't mean it has to be a web-app. MVC is a clear segragation of your business, routing and view needs.

    Give time. The patterns will chase you very soon :)
  • 9. Re: Design Patterns
    807569 Newbie
    Currently Being Moderated
    Honestly: do you understand what design patterns
    are?
    I do. At least I think I do. I have read a similar book and I have tried to use Singeltons, Factorys, MVC and others in some of my projects. I do know that what you need depends on what you want to do. Maybe my question was not specific enough. I just wanted a more experienced opinion on this subject. I wanted to know if more experienced programmers have come across a special pattern more often that others. If you find a certain patten especially usefull and if you think that I should give it a closer look because it helped you in many ocasions. I am trying to get a deeper understanding of patterns but I find it hard to make the transfer from reading a book to designing the project. Thats why I wanted to ask if you hade favorites that need to be given a closer look.
    If you think that the question is not "valid" because you yould not give me an advice on a car without knowing where I would use it than thats fine. But if somebody told me that he just started driving I could tell him to get a car thats easy to handle, not to big, save and cheap :-).

    Message was edited by:
    MartinReckmann
  • 10. Re: Design Patterns
    807569 Newbie
    Currently Being Moderated
    In my experience, you can't begin using design
    patterns unless you have seen them in action
    somewhere. Most design patterns are nothing but a
    common-sense solution to an existing problem.

    I would suggest you keep them aside and design your
    application as you would do normally. Then take a
    close look at your design. Maybe your have five
    components talking to each other in dis-orderly
    fashion. Time to look at Mediator pattern. Maybe you
    are constructing objects of a certain Manager/Service
    class repeatedly. Time to look at Factory patterns.
    If you are designing a web-app, then MVC is a
    de-facto pattern. Of course, doesn't mean it has to
    be a web-app. MVC is a clear segragation of your
    business, routing and view needs.

    Give time. The patterns will chase you very soon :)
    This sounds like a good advice. Thank you very much for answering.
  • 11. Re: Design Patterns
    800322 Newbie
    Currently Being Moderated
    If you think that the question is not "valid" because
    you yould not give me an advice on a car without
    knowing where I would use it than thats fine. But if
    somebody told me that he just started driving I could
    tell him to get a car thats easy to handle, not to
    big, save and cheap :-).
    And what if he has to transport a 20 ton something? What if he's supposedto win a dragster race? What if he's supposed to cross the Atlantic(note: I said vehicle, not car)? :)

    I think the understanding of pattern improves with the understanding of general OO design. If you know where the weak points in OO designs could be, then you can understand how patterns might remove them.
  • 12. Re: Design Patterns
    807569 Newbie
    Currently Being Moderated
    And what if he has to transport a 20 ton something?
    What if he's supposedto win a dragster race? What if
    he's supposed to cross the Atlantic(note: I said
    vehicle, not car)? :)
    Then he would not have told me that the project he needs the vehicle for is a typical "drivers school" problem and that it will not be to complex... (As I did in the first post.) :-)

    Thank you for answering.