How to teach Design Patterns to a team_问答_开发者

I'm a huge fan of the classic Design Patterns book. I very diligently worked to learn most patterns and how they are used (and when they should be avoided). However, I frequently encounter teams where I am the only one touting the book on a regular basis. I was hoping that learning this book would make it easier to explain concepts to other developers, but most have yet to invest the time to learn such topics.

These are major systems that need a solid architecture. I don't want to开发者_开发问答 constantly say "read the book". How do I encourage the regular use of design patterns without coming across as pompous? Has anyone been successful in having an entire team learn and use design patterns?

I would suggest not evangilizing design patterns, instead advocate specific designs/approaches for specific problems as they are encountered.

Later when a similar situation occurs, you can harken back to the approach you took for the earlier problem. Then you can call it a "pattern" that the team has seen used to solve real problems with real benefit.

I would also not strictly adhere to the design patterns in the book for their own sake. It may blind you to good suggestions from non design-patternistas or blind you from real problems that may be specific to your environment/problem domain.

Code review.

Forcing them to use design patterns will likely lead to overuse and anti-patterns.

I confess that I've never tried to do this, so I'm drawing on general observations about how teams can improve their skills and the quality of what they produce. How do people learn? Reading, experimenting, imitating, mentoring ... even listening to lectures! I think you'll need to apply several different approaches. I'd say that two things are critical: exposure to ideas and feedback.

Hence for a team I would do the following:

1). Design and code reviews. The reviews not to be conducted only by seniour people. Have juniors also read code and comment. Ideally they learn too.

2). Design wokrshops toss problems around and come up with alternative solutions.

In both cases I'm less concerned with Design Patterns (the book) than in inculcating a spirit of evaluation and consideration for design. What's good? What's bad? What forces and compromises lead to this particular solution. When is good enough enough?

Take a problem well known to them.
Identify the pattern that can solve the problem most effectively. And solve the problem with the pattern and also implement the solution and show them working.
Don't tell them yet about the Design Pattern. Repeat this for about 3-4 problems. Later tell them what you did was solved a problem with design pattern - Name each pattern and give them reference books or URL pointers for their further study and research.

Don't force them to read the book, this won't work.

Simply refactor their code using a design pattern, and show them why this is easier.

Also give them some time to learn the new way of working.

Get a couple copies of "Head First Design Patterns" and ask folks to read it. It's a fun way to learn about patterns.

I teach a Design Patterns course for the Johns Hopkins Engineering Program for Professionals (evening Masters degree program), and regularly hold brown-bag lunches at work to talk about patterns.

I'd recommend holding a one-hour brownbag lunch once or twice a month. Talk about the concept of the pattern and show some programming examples.

Every lecture I talk about the Golden Hammer -- learn how to use each pattern and LOCK them in your toolbox until you need them!

My favorite technique is what I call "Pattern Theatre". Each of my students researches a pattern and writes a 2-3 page script that uses the pattern in the real-world. For example, I present a theatre about Paul Revere's ride to describe Observer. (Robert Newman see the British and lights lamps; Paul Revere sees the lamps and starts riding and yelling; some townsfolk hear him and hide; some townsfolk hear him and grab their guns - discrete stimulus/response pairs) Nothing in the theatres mention programming; they're all about getting the concepts down before I start the programming part of the lecture.

Reading the book only gives you 'insight' into Design Patterns and I believe that that light only clicks after having implemented some patterns. It may be advisable in your situation to set up a peer review and observe finished code to see where a pattern may have alleviated a particular problem.

Since you didn't mention a source, I will assume that you are talking about the GOF book and if so, I also assume that you are working in a statically typed language such as C++, Java, C#, etc.. If not, then many of the patterns may not even apply to your problem domain and will probably sideline your efforts for team adaptation. For example, Visitor (double dispatch) is not used in dynamically bound languages, Scala has Singleton baked in, etc..

Preaching doesn't work. Lead by example.

When you are working on a design, grab your design pattern book(s) and open it up. Even if you have memorized all of the patterns, open the book.

When someone asks you a design question, don't just tell them the name of a pattern, grab the book, open it to the pattern, point to the relevant part of the pattern, and say something like "oh, hear it is, I'm not sure, but I think this might be helpful".

If the majority of your team views you as a design guru and they constantly see you referencing a design pattern book, they will make the connection on their own.