How many design patterns do you guys really use in your development and what are they?

Not a lot. A lot of them are C++/Java-ism to deal with their shortcomings during GoF's era. PEAA (https://martinfowler.com/books/eaa.html) is used more, when appropriate, higher level integration with systems.

Mostly used as a short, common terms for communicating and documenting ideas.

I wonder why some interviewers are still asking on this. Even some youtuber still teaching this. I guess because of their legacy system



This post has been edited by codercoder: Sep 15 2023, 03:01 PM

Just cargo culting using the terms without understanding *why* we're using them. Might have legitimate reasons to ask for it, but sounds like just fishing for people who know how to answer retro trivia.

https://en.wikipedia.org/wiki/Cargo_cult

could be

In the past, have any interviewers asked you on this?

No. I've not been an interviewee. Only interviewer.

I've seen a few codebases that may have independently arrived at the Singleton Pattern

Even if you don't go out of the way to use the patterns yourself, you can find them being used in the frameworks or libraries that you might use daily.

Java developers use Abstract Factory every time they have to get a JDBC connection to a database or JMS connection to a message queue.

In all editions the book "Effective Java" (up to 3rd now) the Factory Method, or rather Static Factory Method, is recommended over plain constructors because:
1. the factory method names can be more descriptive than just the class name.
2. being able to have different factory names means that you're no longer restricted by the constructor's method signature when defining your parameters.

If you've used any of the ReactiveX implementations, like RxJS, Observables are an implementation of the Observer Pattern

Java's Servlet Filters implement a form of Chain-of-Responsibility, passing the entire HTTP request down the chain to any code that may want to manipulate it.

Java Persistence with lazy loading makes use of Proxy objects around your Entity classes, only making calls to the DB when you actually want to read the data.

Yeah, the library and framework are implementing design pattern.

AddDbContextFactory and IHttpClientFactory in the context of ASP.NET Core are examples of the Factory design pattern.

But I am curious on what are the common design patterns we wrote and the problems they solved.

From my experience, you'll bump into some versions of the GoF patterns in almost any project.

However, in my opinion, these patterns are most applicable to OOP languages such as Java and C#.

This is not to say that you won't be using them in other languages.

For example, Go isn't an OOP language, but I've used/seen patterns such as singleton and factory.

Hmm, if you've ever "mocked" a service to run a unit test, then you've used the Strategy pattern.

If you've ever had a giant class that just routes function calls to other classes/objects, that's a Facade.

When a framework asks you to inherit some abstract class then implement a bunch of abstract methods, there's probably a Template Method in the abstract base class.

Want to do some operations before, after or both before and after a method, without changing the class itself? Override the method in a child class, put a call to super.method() in between the new stuff. You've just implemented a Decorator.

Singleton in dependency injection is different from Singleton design pattern right?

They are the same to the extent that throughout the entire lifecycle of the program, there is one, and only one, instance of the class.

The original GoF Singleton pattern uses the language features of a private constructor, and a static getInstance() method to enforce having only one instance of the class in existence. The first time getInstance() is called, the constructor is called internally, and that same instance is returned on every subsequent call of getInstance().

With dependency injection, the DI container controls the creation of objects within its "context" for you. By default you just get one instance, hence it's effectively a Singleton. However it's possible to instruct the DI container to create more instances, or even call a constructor yourself, if you wanted to.

Off the top of my head

• Observer
• Strategy
• Adapter
• Proxy
• Decorater
• Chain of responsibility
• Iterator (its built into most language constructs these days)
• Command

Probably a few more that I do, but I'm not aware of what its actually called.

Its almost impossible to not hit at least 1 of the patterns above when doing any dev work.

THe coding patterns help developers to write cleaner and understandable code.

When you write in those ways, you do not have to worry about performance or bottle related issues, you can focus on delivering outcomes.