Patterns

Can anyone suggest some good books on OOP architecture patterns? How important do you consider design patterns to be when building the Architecture baseline of you software applications?

This is one of the best I've read about design patterns.

Design Patterns,
Elements of Reusable Object-Oriented Software
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
Hard-cover, 416 pages, Addison-Wesley 1995, ISBN 0-201-63361-2.

In my opinion design patterns are very important when designing the architecture of a software application. When you know about design patterns and also anti-patterns, you have an idea of how to attack certain design issues in a proved way and which things you souldn't do.

Personally design patterns helped me to think in a structured way about object oriented designing. A big advantage of design patterns it that it gives you words so you can identify issues and talk about that issues with other designers. For example, a design issue can be identified as Abstract Factory. And when talking with other designers, they understand me when I'm saying it.

they understand you because somebody TOLD them. i.e. everything does not have to come from within; there are somethings we don't have to know. i could spend all of my time re-inventing things that have been done over thousands of times...or i could spend my life inventing things...that haven't been invented before. or like most people; i can spend my life doing a combination of the two; i.e. inventing and borrowing technology...innovating.

>they understand you because somebody TOLD them.

?

Thanks, I'll look into that title. It seems that the OMG community is big on patterns, as well as those at rational.com

I'm reading about the rational software development process and trying to apply it to the UML. I don't know anything about patterns as of yet, however it only makes sense that they are extremely valuable when guiding the project architecture. They say that OOP issues are circular.

Patterns and anti-patterns are valueable during developing the architecture and designs. Recently I've been to a lecture about organisational patterns, it seems that patterns are used everywhere these days.

When creating a design, you recognise some design issues as a pattern (when you know about that pattern). And because you can relate the issue with the pattern, you know what to do and what not to do. That's one of the goals of design patterns, sharing experience. Another goal is having the same vocubulary, so you don't need much words to explain what you mean.

What do you mean with OOP issues are circular?

I picked up the book today. Look great.

I meant that OOP issues seem to reccur. I guess I'm asssociating it with recurring solutions to problems in the problem domain.

I want to apply the patterns to my baseline architecture and than use the rational unified process to guide my development of the software program. In the past I had learned about the waterfall approach to system development however since they leave testing and integration until the implementation part of the lifecycle, instead of iterative an incremental process lead by use cases I find it difficult to continue reading about it. The patterns will take some time to understand but I think it will be more beneficial to learn how to use them when it comes time that I want to create a large software project.