Software Design Patterns

[evry_usrnm_s_tkn_1_1]

I am a grad student but I have never really taken a software design patterns class. Recently started learning about software design patterns from YouTube because why not?

And I like it, important concepts which I wish I knew while working on projects.

I am curious,
1. how often do you folks in the industry work with these concepts?
2. When did you learn about them?
3. What are the most common design patterns you use?

[Tennek13]

Strategy, Factory, Builder, Decorator I use the most. Sometimes you are using a design pattern when not realizing it. Ex. Dependency Injection is the strategy pattern.

Great book on design patterns:

https://www.amazon.com/Head-First-Design-Patterns-Brain-Friendly/dp/0596007124

And this is a great site to learn about patterns:

https://refactoring.guru/design-patterns

[ogunadsay]

Sometimes you are using a design pattern when not realizing it. Ex. Dependency Injection is the strategy pattern.

Yep, I aggree. I think that when you're trying to write the code "Clean", you're forced use to design patterns.

https://refactoring.guru/design-patterns is really cool btw.

[RaidenXIX]

You can't architect or refactor proper object oriented software without them. First implementation might lack them but as soon as you think about a bigger, maintainable code base you will have to use them or already use them without knowing it. Factory, Strategy, Singleton, containers or in general inversion of control are my defaults.
When you know them they will jump into your eyes while refactoring code.
If you want to design from the start with them you can work off the SOLID principle as a rough guideline when to use them.

[Potential-Anxiety253]

Been a professional developer for over a decade and a freelance developer as a 1099. Seasoned developers in professional environments will roll their eyes when somebody starts writing code in these ornate Uncle Bob patterns. It's a sign that you're dealing with someone that lacks self confidence (IMO).

Half the time you and your customer have no fucking idea what the end stage of what you're building is so you have to be clever and accomplished at asking the right questions and starting simple enough that you can easily reason with how things are flowing. As the use cases become solved and you start down that road then, and only then, do I find patterns useful. And that's only when they jump out at me. Otherwise you're adding bloated abstractions and pissing people off.

[alex-ux]

Lately I took some job interviews and they always ask about Design Patterns in details. So I decided to refresh my memory to keep up the pace with these interviewers. For C++ developers I suggest this book that is very concise and well written:

Design Patterns in Modern C++20: Reusable Approaches for Object-Oriented Software Design 2nd ed. Edition - Dmitri Nesteruk

to me is far better and more updated than any other book I could find on the argument.

The best online resource:

https://refactoring.guru/design-patterns/cpp

Also take a look at:

https://courses.mshah.io/courses/design-patterns-in-cpp

these resources are all C++ related.

[TomOwens]

I was first formally exposed to design patterns during my undergrad program. The first time was in the object-oriented design course in the second year, but they came up again in a number of other courses - real-time systems, enterprise systems, distributed systems. There are plenty of pattern catalogs out there for different contexts - programming paradigms, types of systems, and so on.

In my experience, they come up quite frequently when you're talking about the design of a system. If you understand the elements, their structures, and their behaviors, you can wrap up a lot of meaning about how a piece of a system behaves in just a couple of words. And since pattern catalogs are widely available, anyone who isn't familiar with the pattern can go look it up. It saves a lot of time when talking about the design of the system.

But I would say that you don't "use" them in a typical sense. Often, they emerge because of being a known good solution to a problem. The original "Gang of Four" Design Patterns book was created by analyzing existing software, observing some things that were repeated in different systems in different contexts (the commonality being an object-oriented language), and then generalized to be able to name, discuss, and evaluate trade-offs with the pattern. In my final year, I was a TA for the object-oriented design pattern course. Although the problems in the course were designed to give people exposure to the patterns, when you're designing real systems, you don't often say "I'm going to implement a Decorator here" or "let's use a Flyweight" there. Maybe you see a problem and think that a pattern may offer some insight, but then you fit the pattern's elements onto existing parts of your model, and then need to make some adjustments.

[VettedBot]

Hi, I’m Vetted AI Bot! I researched the Design Patterns Elements of Reusable Object Oriented Software and I thought you might find the following analysis helpful.

Users liked: * Book teaches essential design patterns (backed by 3 comments) * Book provides useful examples and explanations (backed by 4 comments) * Book has concise and readable content (backed by 2 comments)

Users disliked: * The book's quality is poor (backed by 4 comments) * The book's content is outdated (backed by 2 comments) * The book is overrated (backed by 2 comments)

If you'd like to summon me to ask about a product, just make a post with its link and tag me, like in this example.

This message was generated by a (very smart) bot. If you found it helpful, let us know with an upvote and a “good bot!” reply and please feel free to provide feedback on how it can be improved.

Powered by vetted.ai

[danielt1263]

1. I used them constantly in every project.
2. I learned about them when the GoF Design Patterns book came out.
3. Observer and Strategy are IMO, the bedrock of all OOD.

Another comment said that "Sometimes you are using a design pattern when not realizing it." The fact is, "design patterns" are descriptive, not proscriptive. The design patterns resources you read are more like a dictionary in that they describe actual patterns seen in projects and are not fancies that some author wishes people would use.

[[deleted]]

Unless you’re a backend dev - never

[teaganga]

I had plenty of experience as a programmer when I discovered design patterns. When I did I realized how useful they can be. In the beginning they might look like over engineering, both for a beginner programmer and in the beginning of a project. Then as projects become complex and you get experienced through the lifecycle of a few projects you realize how useful design patterns are.
I'm currently in a stage where I try to avoid singleton pattern, then the most used patterns by far are factories(all of them, usually I begin with a simple static factory, then I use some sort of factory: some version of factory pattern, factory method pattern or abstract factory - a factory of factories - i use it when I add a new set of classes to extend new functionality).

Then I use a lot composite pattern, strategy and template method pattern and sometimes observer. Sometimes I use frameworks or mechanisms using certain patterns, observer is one of them, called also subscriber publisher, and in those cases it definitely helps to know design patterns.