Aren't Design Patterns an extension to OOP principles? Why are these two concepts treated separately? Can we believe that if someone who knows Design Patterns would definitely be an OOP expert?
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.
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.
Design Patterns are common approaches to solving problems that come up on OOP programming. Knowing about design patterns can save some time when determining how to approach a situation.
Some design patterns allow you to do things that would be otherwise impossible or complicated such as the Visitor Pattern which allows a set of classes to gain new functionality without any knowledge of the change. Using normal OOP techniques, one would make an interface or virtual methods that each class implements. Which goes against the OOP open/closed principle.
I would not go so far to say that someone who knows design patterns is an expert OOP though.
Programmers use patterns all the time without ever studying them since they are use extensively in the Java and .NET frameworks. Most of the Java IO namespace is comprised of classes taking advantage of the Decorator pattern. Knowing that doesn't make someone more or less of an expert in OOP but it can help make sense of things.
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.
The concept of Patterns and Anti Patterns applies also to non-programming domains.
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.
Object Oriented Programming is a programming methodology or concept of programming that organizes code into objects and relationships of objects. Design Patterns would suggest proven-successful methods of constructing types/objects to solve a certain scenario in a program.
This is a limited definition.
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.
Object Oriented Programming = Cooking
Patterns = Recipes