What are other design patterns besides MVC?

Zenith

I had an interview with the Angular club the other day and they wanted to know what design patterns I used.

Obviously, they wanted to hear MVC, but I asked for some examples. All they came up with was "inversion of control" and "dependency injection." I have no idea what makes them design patterns in the sense that I understand them.

All I could think of besides MVC was client-server. Then I started to wonder, what "design pattern" covers a regular application? I mean your typical Windows desktop application or classic ASP/PHP website. What are they even called in Framework Microservice Town 2019?

Unperverted Vixen

@Zenith said in What are other design patterns besides MVC?:

I had an interview with the Angular club the other day and they wanted to know what design patterns I used.

Obviously, they wanted to hear MVC, but I asked for some examples. All they came up with was "inversion of control" and "dependency injection." I have no idea what makes them design patterns in the sense that I understand them.

Going strictly by the definitions and examples in the classical Design Patterns book, MVC isn't a design pattern, it's an implementation of multiple design patterns: "...the main relationships in MVC are given by the Observer, Composite, and Strategy design patterns."

I think "architectural pattern" is a more common term for that level of design.

Then I started to wonder, what "design pattern" covers a regular application? I mean your typical Windows desktop application or classic ASP/PHP website.

WPF should be using MVVM (a variant on MVC).

WinForms/WebForms (and from what I know of them - not much - classic ASP/PHP) aren't really using any patterns, per se, but are more pure procedural programming.

What are they even called in Framework Microservice Town 2019?

You think they do up-front design work. How cute.

TheCPUWizard

For the "Classic" (but not exactly correct) information on Design Patterns see the book: https://books.google.com/books/about/Design_Patterns.html

But the answer is really even easier.... Design Patterns are anything that is done on a recurring basis. Some are published, but many more exist privately. Key to their effectiveness is documenting when they are (likely) applicable as well as conditions where they do not apply.

For teams I have mentored, one of the first things that gets setup is their own book. When I first started doing this (nearly 25 years ago) it was commonly a physical looseleaf binder, these days it is much more commonly a wiki or similar.