views:

179

answers:

6

I've studied and implemented design patterns for a few years now, and I'm wondering. What are some of the newer design patterns (since the GOF)? Also, what should one, similar to myself, study [in the way of software design] next?

Note: I've been using TDD, and UML for some time now. I'm curious about the newer paradigm shifts, and or newer design patterns.

+1  A: 

A huge change from a maintenance aspect is the use of DVCS. If you don't know what one is or haven't used one, I highly suggest reading up on the two hard hitters:

Mercurial (hg): http://mercurial.selenic.com/
git : http://git-scm.com/

They've done quite a bit to change the workflow of the common programming environment. Not really a pattern/design I spose, but I don't think TDD or UML are technical patterns/designs either at some level. Maybe more like common practices surrounding programming.

xyld
I wouldn't consider VC related technologies to change the work flow very much. I did consider TDD and UML because it changes your approach to designing and working out a problem.
monksy
-1, not related to design patterns
harto
+2  A: 

I am an avid follower and supporter of the PCMEF (now PCBMER) framework

Here's a simpler overview of it.

It kind of understands that enterprise systems are huge an complex, and by combining a bunch of other design patterns together into the PCMBER framework (Presentation, Control, Mediator, Entity and Resource), even the most complex system remain easy to usnerstand and manage.

Michael Rodrigues
Interesting.. I'll have to take a look at it.
monksy
+4  A: 

There is roughly an infinite number of design patterns. Design patterns are just that: a recurrence of tricks programmers use to get things done. The most useful thing about the GoF patterns is how famous they are. In that, they have become a language -- exactly what the GoF hoped to achieve.

Many other patterns you'll find on the web and in literature are "just" useful tricks, not so much a language you can use when you speak to fellow programmers. That said, there is a number of patterns that arose in the past ten years or so, particularly in the realm of web development. See the patterns listed in Martin Fowler's patterns book.

wilhelmtell
I wouldn't say patterns are "a recurrence of tricks." I think there is quite a bit more to it than that. Creating a good design requires forward thought and understanding of how the system works, how it will grow, where flexibility is required and where it is not. There are many tricks that programmers use to make their life easier, but tricks aren't necessarily forward thought into the design of the system. Others may disagree, but when I hear "tricks," I think "shortcuts" and not solid, software design.
JasCav
@Jason what does this have to do with design patterns? When you solve a design problem and then use the same idea of a solution to solve the same problem elsewhere, you use a design pattern. It's not promoting planing, it's a recurrence of an idea for solving a design problem. It takes experience for using design patterns effectively, and like picking a language if you do it out of religious views you're going to fail miserably. You don't _have_ to use design patterns to do something right, and very often you use design patterns without even noticing it.
wilhelmtell
@WilhelmTell - The reason I said what I did is due to how you phrased your answer. To say that design patterns are "just tricks" and that the GoF is only useful because "they became famous" is completely ignoring the fact that a good design requires planning and an understanding of how to build that design with an understanding of WHY you are using a design. Sure, I can accidentally stumble onto a good design, just as a architect can stumble upon a good structure for a building. Doesn't mean the software or the building is designed well. Design patterns are more than just "tricks."
JasCav
+2  A: 

One of the newer ones that I found particularly useful is Domain Driven Design. Not so much a pattern in its own right, but more of a mindset - to concentrate on the domain objects - i.e. the things that you model and build the rest of application around it.

I found that it gave meaning to principles that we all knew before but were too lazy to deal with - like Single Responsibility Principle and Separation of Concerns. I take those two especially more seriously now.

Another axis of improvement for me was TDD and Dependency Injection. I have discovered that with lots of interfaces and classes implementing them I was able to let go of this fear of only defining something once. That is not to say that it is in conflict with DRY(Don't Repeat Yourself) much. It's OK to have two classes with the same properties if their purposes are different. Encapsulation and SRP are much more important than only defining a property once.

Igor Zevaka
Thats kinda what I've been looking at. From the stuff resulting from OMG ... I find that not much changes from GOF.
monksy
DDD is not a design pattern. It's an architecture style combined with a style of customer-management.
George Mauer
+2  A: 

Umm...none of the things people have mentioned are design patterns.

GOF was written implicitly with Java in mind. It explored that space pretty well. However once you go into other languages some patterns are no longer necessary (Observer is rarely used in a language like C# that supports events) and some new ones spring forth. Grab yourself the Pro JavaScript Design Patterns or Design Patterns In Ruby books and see what happens to the stand-by pattens in these very different paradigms.

My favorites lately have come from leaning on the functional drift of modern languages. I'm a big fan of nested closures and of the functional ways of tackling some of the same problems that GoF does (again, see the Ruby book for great examples). I also am currently in love with the idea of internal domain-specific languages which open up into a whole series of design patterns of their own (including nested closures). Also event-aggregation seems to be poised to hit it big in the .Net world in the near future.

A couple other big ones that have hit the scene but aren't discussed as much in GoF - probably because they are more high level then what those guys were going for - are Inversion Of Control Containers, Message Bussing, Aspect-Oriented-Programming, Model-View-Controller, Model-View-Presenter, Model-View-ViewModel, and their ilk.

By the way, these are not design patterns, but if you're looking to progress beyond TDD start looking into Behavior-Driven-Development and Context/Specification.

George Mauer
+1 : the GoF patterns are Java-esque, different language have different idioms.
Paul Nathan
I'm surprised by your comment that Observer is rarely used in C#. It's incorporated into the language ("event" type) and the ability to add multiple subscribers to events with the += operator. The .NET framework provides interface definitions for property and collection change notification; these are crucial for databinding in WPF and Silverlight. If "Observer" pattern doesn't get called out much, it's because it's become a core concept.
Cylon Cat
@Cyclon that is exactly my point. The need for observables is still there, but the implementation posed in GoF is rarely used (I haven't looked at IObservableCollection yet but it might do something similar), it has been supplanted by a language feature.
George Mauer
+1  A: 

I'm surprised that no one has mentioned Martin Fowler's book Patterns of Enterprise Application Architecture. This is an outstanding book with dozens of patterns, many of which are used in modern ORM design (repository, active record), along with a number of UI layer patterns. Highly recommended.

Cylon Cat
Again, want to point out that those are not really design patterns, they are architecture patterns. Similar, but much higher level.
George Mauer