How important are design patterns in web development? [closed]_问答_开发者

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit 开发者_开发知识库debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 9 years ago.

What are the design patterns that I should be completely familiar with? And what is one easy example that each can be used for?

I am a web developer (I use Django, and is familiar with separation of logic), but I work at a Desktop-app company. They are always talking about singletons, and I forget...but it leaves me no clue!

MVP or MVC

Model View Presenter or Model View Controller

More architecural patterns but neverless, they are a combination of design patterns.

Forget Singleton. It's confusing and rarely necessary.

Learn State, Strategy and Command. They're used all the time.

State is for anything that has logic that depends on the state of the object. In short, every if-statement might possibly be better done via State. Seriously. Too many if-statements are a code smell and indicate that there's stateful processing that's sprawled all over the place.

Strategy is for any "plug-in" or "expansion" or "option" processing.

Command is for any extensible (and composable) set of actions. Backup, Restore. Table Drop, Create, Index, Populate. Validate, Load, Summarize, Report. Any of those command-like things that can be put together in different ways, different orders, etc., should probably be done with a formal Command design.

Honestly, patterns are important but knowing when to use them is just as important. There is never going to be any set answer it is something you need to feel out for yourself. People that fight about it being an absolute where you should always use them or always not use them are incorrect. Design patterns are a tool. I would suggest looking at Amazon.com for a book in whatever language you are writing in that deals specifically with design patterns. I know there is one written for Ruby on Rails that is great though I don't remember the name, there is also one for Java called Head First Design Patterns, and on for C# written by Bob and Micah Martin that is excellent. Read whichever one of those that applies to the language you are most familiar with. Even if you don't use all of the patterns it is good to understand how they work and when they will be useful to use.

Knowing design patterns won't be much use until you know why they are the best strategy for a given problem. Learning design patterns from the very beginning is probably fine, except you've missed all the "wrong" ways to solve that problem, which in turn means you may be missing subtle difference in when to use the given pattern and when to not use it.

The only thing worse than people who stick to their old ways and don't bother learning the proper way, is people who learn the proper way and don't bother learning why that way is proper. And they keep applying it to stuff that it shouldn't be applied to, because they just don't know better.

So my point is, if you're new at web development, don't be too caught up in the design pattern hype (though it's a good hype). Learn by doing stuff yourself. When you've reached a certain level, read up on design patterns and see where they could have been applied to have made your code better.

THAT is how you learn them properly. Not like being forced to run before you can walk.

For web applications, understanding at least at a rudimentary level the patterns described in Patterns of Enterprise Application Architecture has proven valuable to me. Gang of Four patterns are worth knowing, too.

But I would argue that you simply don't need encyclopedic knowledge of patterns to get started. A cursory understanding will help you understand where to look when you start to encounter friction between your ideas/business problems and your code. I had a couple of weekend trips that allowed me to plow through these two books in their entirety, but I still find the detailed information in the patterns section more useful as a reference than as background knowledge.

Reading just the "Part 1" sections of the GoF or PoEAA will help you far more than learning three or four patterns in depth, because you'll know where to look when you encounter problems they describe. And you can look up the details of most of the patterns they describe online.

GoF patterns that I use directly or indirectly, often unconsciously, in web development, include: Observer, Command, Composite, State, Strategy. I usually don't use Singleton except as a client of logging and service locator/dependency injection tools. PoEAA patterns that I use regularly, usually unconsciously, or incidentally as a part of the data access strategy or web framework I'm using, are Active Record, Application Controller, Data Mapper, Domain Model, Gateway, Lazy Load, Layer Supertype, Page Controller, Template View, and Value Object. That's not exhaustive; these are just a few that popped into mind.

Most of those are probably more usefully learned by starting with an opinionated web development framework, like Rails, Django, or Castle Monorail, than in the abstract. After all, patterns were identified and extracted from thousands of successful app development experiences, not invented and then glued on because they sounded clever.

It's pretty easy to get overly excited by better-than-superficial knowledge gained on one or two patterns and then seeing "only nails" for every problem you see shortly thereafter and trying to hammer an ill-fitting pattern into a solution because you understand how it works.

So, learn patterns, yes; get a superficial overview of the motivations of all of the commonly used ones, but don't feel like you have to wait to write serious code until you understand some arbitrary list of them.

MVVM is a newer one I have seen used with Silverlight. It's a bit much, but it seems effective.