How is OOP and Design Patterns related? [closed]

Question

A Design Pattern is a tried and tested solution to a common programming problem. It doesn't necessarily have to be an Object Oriented programming problem, but that is most common these days.

Learning to program is not hard for many people. It's like playing with Legos: there's a handful of different pieces you get to snap together however you want. Sometimes you make something cool, but most of the time you make crap =). Usually, the longer you play, the better you get.

Studying Design Patterns is learning good ways to build your programs. You're essentially reading advice from people that have been building things for decades. They've distilled their most common solutions into simple, digestible tidbits of knowledge with memorable names. It's like an apprenticeship for the digital-age: your elders are giving you their best advice. You can take it and be ahead of the game, or ignore it and repeat all of their mistakes.

Why are design patterns and OOP treated separately? Because they are different subjects. In general, you learn to program, then you learn how to think about programming. I wish it were the other way around, but I'm not holding my breath.

Is someone that knows Design Patterns necessarily an OOP expert? No.

Design Patterns and Object Oriented Programming are not necessarily related. It so happens that a large number of design patterns involve Object Oriented Programming.

A design pattern is a commonly used approach to program creation. The approach of finding the common pattern language for a field can be extended to functional programming or bridge building or come to where it began, in architecture. OO is a specific conceptual paradigm, which some programming patterns fit into.

The situation is like a Venn Diagram - the approaches aren't opposed but they aren't identical and they operate on somewhat different logical levels.

Aren't Design Patterns an extension to OOP principles? Why are these two concepts treated separately?

"Design Patterns" are about OOP principles mainly due to a historical accident.

I'm fairly certain that ML hackers were talking about folds of algebraic datatypes long before the GoF book. That's a tried-and-true solution to a common problem: you want to compute a single value based on the contents of some algebraic datatype. Similarly for map, I figure.

I think the general (meta?)practice of discovering and codifying solution templates is quite old---isn't that essentially what "Best Practices" are all about?

I figure the reason why DPs and OOP are treated separately is because although they overlap---one would think that OOP best practices have something to do with OOP principles---there's some independence: it makes sense to talk about design patterns in a non-OO setting.

I think you should pick up any design pattern book, and read the introduction. Once you get what's a design pattern, you'll have this question answered.

In truth Design Patterns and OOP don't really have anything to do with one another. They are, as they're name suggests, patterns (or "recipes") for implementing a design. There are "design patterns" for virtually any language you'd work in but it happens that the Gang of Four book focuses on OO design patterns.

A knowledge of OO design patterns can be a positive indicator, but when interviewing someone (or trying to gauge their level of expertise), I would look at the complexity of the patterns they are familiar with, as well as a good knowledge of when/where to use a pattern. I've seen developers latch on to a pattern like a "golden hammer" and use it in places where it's not necessarily applicable.

So just like a recipe book doesn't make one a master chef, knowledge of OO Design Patterns, does not necessarily make one an OO expert.