How to design using patterns_问答_开发者_运维开发者技术经验分享

I am a college student and I'm learning about software patterns (specifically the ones mentioned in the GoF book). I have never been that good at software design, but I'm learning how each pattern works and solves different problems to produce more flexible software. I have a questio开发者_如何学JAVAn that has been bugging me.

What's the best way to look at a problem (a piece of software that needs to be written) and determine how to organize it and apply patterns? I recently had a group Java project that went really sour because our design just wasn't very flexible. I honestly just had a great deal of trouble trying to break down the problem into manageable pieces to sort out. I know I can write code, but I don't know how to organize it.

The patterns I have gone through currently are Composite, Builder, Adapter, Proxy, Observer, State, Strategy, Template Method, and Iterator. Like I have mentioned, I know what they are supposed to solve, but I feel like I am trying to force patterns into place. Any help or links to pages would be greatly appreciated. Thank you all!

Unless you are uncommonly intuitive (like the dude who never has to try to get a 4.0, or your at a place as depicted in the movie about the facebook guy where everyone is a genius and Bill Gates comes to guest speak) then there's a certain amount of pain that is unavoidable before the mental constructs that really don't exist anywhere else but in the subject of object oriented programming become part of you natural reasoning process.

Once that happens, and it will if you don't give up, then patterns like that will start making sense and helping, but probably not before you've already stuggled with the problems that they solve quite a bit.

I don't know that I agree with the way CS is being taught to undergrads these days. In 1994 at Rutgers I took C data structures and Computer Architecture as a freshman. The patterns I learned were things like "linked list" and "abstract tree". This was the foundation for understanding higher level stuff.

You mention issues with basic application problem solving. You need to work on that first before getting heavy into patterns. Patterns are not the way to learn design - they can add complexity and often somewhat obscure a design unless you have advanced your skills to a certain point.

Work on decomposition of a problem into fundamental pieces and creating a rational set of objects that correspond to domain knowledge and fundamental problem elements. Also, create UML diagrams. You don't have to worry with all the details of a formal UML implementation, just use basic blocks and associations to represent your model. Also don't try to do one diagram of the entire app, just diagram important pieces. Diagramming will improve your ability to visualize the problem, how it relates to the design, and the process of translate from a problem to a model to code and code back to model back to problem.

UML is also a useful check and balance process. A diagram should make logical sense. If you cannot create a logical diagram you may have a problem, and diagrams also help find pieces that fit poorly. UML also typically "leads" code in terms of clarity and complexity. By that I mean that often a diagram will still be reasonably clear well past the point when the code is becoming too difficult to work with. So conversely, if your diagram is already becoming too complex or unclear that is a dead give away the resulting code is potentially unmanageable and you need to rethink the problem.

Once you feel like you are getting better at decomposing a problem into small parts and designing and naming classes that fit your analysis you can begin to slowly incorporate patterns. Start with creation patterns first. Many times a Singleton is needed and most applications of any complexity can benefit from appropriate use of Factories.

After that you should be able to find more and more how structural patterns are used. Facade is easy and one widely used - encapsulate a lot of things into a simple interface. Decorator, Composite, Proxy, Adapter are all about making object "type identity" appear to behave differently, learn the similarities between them and why each one is different and where to apply them. Finally, behavioral patterns are typically used in either state management scenarios or some sort of object - to - object communication aspect. Mostly they are suggested by certain types of problems, example Memento is suggested by need to perform roll backs or persist state.

Work on your basic design skills first, don't overdo patterns and incorporate them gradually, starting with creational patterns first.

Trying to "force" a design pattern is not the right approach.

If you have existing code, it's best to approach this from a refactoring perspective. Look for the "bad smells". What are the actual problems? It might be the case that there are so many basic problems with the code (functions too long, excessive duplication) that you need to address these before you can look at it from a higher level.

Once you've cleaned up the code on a basic level, some higher-level problems might emerge, and here is where the pattens might help. But, rather than saying "how can I use THIS pattern", it will more likely be that you'll look at a problem and say "AHA. This is perfect for the decorator pattern". This might not happen, but you'll be more open to finding the pattern once you've studied the book.

A good term here is serendipity.

Patterns are not only a programming tool but also a communication one as well. When there are tens or hundreds of thousands lines of code you need to be able to find your way round, visualise parts and be able to talk to fellow developers about the code effectively. Patterns do this.

The GOF patterns are a good starting point to learn about them but you need to apply them to a situation, not create a situation to use them.

When you get better at applying patterns to the right situation start expanding your knowledge on enterprise patterns and start to see how patterns can be connected together. The latter will start to emerge the pattern of application architecture.

Trust me it can take a long time and experience to get good at them and knowing when to apply them. Just be patient and be curious at the same time.

Bill Venners: Is the value of patterns, then, that in the real world when I feel a particular kind of pain I'll be able to reach for a known solution?

Erich Gamma: This is definitely the way I'd recommend that people use patterns. Do not start immediately throwing patterns into a design, but use them as you go and understand more of the problem. Because of this I really like to use patterns after the fact, refactoring to patterns. One comment I saw in a news group just after patterns started to become more popular was someone claiming that in a particular program they tried to use all 23 GoF patterns. They said they had failed, because they were only able to use 20. They hoped the client would call them again to come back again so maybe they could squeeze in the other 3.

Trying to use all the patterns is a bad thing, because you will end up with synthetic designs—speculative designs that have flexibility that no one needs. These days software is too complex. We can't afford to speculate what else it should do. We need to really focus on what it needs. That's why I like refactoring to patterns. People should learn that when they have a particular kind of problem or code smell, as people call it these days, they can go to their patterns toolbox to find a solution.

Bill Venners: That's funny, because my second question was that I have observed that often people feel the design with the most patterns is the best. In our design seminar, I have the participants do a design project, which they present to the others at the end of the seminar. Almost invariably, the presenters want to show off how many patterns they used in their design, even though I try to tell them the goal is a clean, easy to understand API, not to win an I-used-the-most-patterns contest. I just heard you say the same thing, that that's not the right way to think about patterns. If not, what is the proper justification for using patterns in designs?

Erich Gamma: A lot of the patterns are about extensibility and reusability. When you really need extensibility, then patterns provide you with a way to achieve it and this is cool. But when you don't need it, you should keep your design simple and not add unnecessary levels of indirection. One of our Eclipse mottos is that we want extensibility where it matters. Actually, if you are interested in how we use patterns in Eclipse I did an attempt to capture their uses in a chapter in the Contributing to Eclipse book [see Resources]. In this chapter I used design patterns to explain pieces of the Eclipse architecture.

http://www.artima.com/lejava/articles/gammadp.html

google parts II - IV too! :) those are great readings