Learning about Design Patterns? (software design)

[smjpl]

I am trying to learn more about design patterns and I am just seeing if anyone here can recommend some good learning material. I have got the Gang of Four "design patterns elements of reusable object-oriented software" book but I am looking for some more current material that maybe is more specific on when to and when not to use specific patterns? What are the most common patterns and which ones should we just avoid (apparently the singleton but that is still in debate).

 

Also any of your own experiences is welcome.

 

Any help is appreciated.

[Paralectic]

I do recommend learning about MVC and the different methods of using it.

[smjpl]

I do recommend learning about MVC and the different methods of using it.

 

I will keep that in mind. Looks interesting. Seems to try implement the characteristics that DP try to implement. Basically loose coupling in order to make code more flexible.

 

I am doing my thesis on design patterns (taught masters, not a research so it is only around a 3 month project). At this stage I am just trying to write my proposal (I start in the summer) so I am just trying to get as much background information as to why you would use design patterns and the dangers of using some of them.

[MikeD]

During my OOP class in uni (3 years ago) we learned a subset of those design patterns and had to apply them to a project as we saw fit.

And by that I mean 2 things:

1) Those patterns are as relevant now as they were in '94;

2) A design pattern is supposed to be a generic solution to a type of problems. Nobody is going to be any more specific about when to use a given pattern/set of patterns.

 

This was what I was going to say before you said this was for your master's thesis. Now I will add that design patterns are dangerous if you try to use them all at once, but the rest still stands!

[smjpl]

During my OOP class in uni (3 years ago) we learned a subset of those design patterns and had to apply them to a project as we saw fit.

And by that I mean 2 things:

1) Those patterns are as relevant now as they were in '94;

2) A design pattern is supposed to be a generic solution to a type of problems. Nobody is going to be any more specific about when to use a given pattern/set of patterns.

 

This was what I was going to say before you said this was for your master's thesis. Now I will add that design patterns are dangerous if you try to use them all at once, but the rest still stands!

 

I should say that I am not going to do all of them or anywhere near that. I am only looking to do a couple of patterns (it makes for a good thesis as I can add some if I am running low on material ).

 

What I mean about looking for more info, I am just seeing if anyone has studied this area a lot and knows of any good papers or articles on patterns. For example I have come across David Budgen and Cheng Zhang who have done some surveys in this area (https://community.dur.ac.uk/david.budgen/).

 

I am just looking for any advice or nudges in the right direction from people who work with these. Is there any I should maybe look into or stay away from? Which ones have been covered a lot and are kinda obvious? Which ones are more specialized and unique? (Apparently the Mediator pattern is obvious and implemented by a lot of people without realising it is a pattern)

[Avratz]

As someone who works on a large, multithreaded code base that makes liberal use of singletons... avoid them.

 

It makes start up and shutdown a pain in the ass.

[smjpl]

As someone who works on a large, multithreaded code base that makes liberal use of singletons... avoid them.

 

It makes start up and shutdown a pain in the ass.

 

I've read that multithreading and singletons are a no no. Basically with multithreading, global state must be avoided at all costs.

 

Do you use many design patterns regularly or seldom?

[addref.release]

<rant>

Frankly, software development is the wild west compared to other kinds of engineering. Every shop/company is different, with its own weird idiosyncrasies and choices.

Every place (and person) thinks they are a unique snowflake, which is ironic, because 95% of the problems they try to solve have been solved before, and usually better.

</rant>

 

Nonetheless, some of the more common "design patterns" (or "architectural patterns" if you like) that you'll encounter out there are:

 

* MV* (MVC, MVVM, MVP, with a hundred different variations on the theme).

* Observer.

* Messaging (e.g. with a bus or broker).

* Dependency injection and inversion of control.

* Object relational mapping (ORM).

 

[BrightCandle]

The best place to learn these is from the original book that introduced them. Design Patterns: Elements opf Reusable Object-oriented Software by Gamma et al.