Tutorial :How is OOP and Design Patterns related?


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?


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.


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.


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.


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.


I think OOP principles are a set of tools that design patterns can be applied to to produce a good program.


Aren't Design Patterns an extension to OOP principles: I think the answer should be NO

Why are design patterns and OOP treated separately?

OOP principles - is actually about which constraints/subjects you should follow when designing/defining a class(Technical representation of an business object)..How the class behave.. What action should be taken to remove any other classes dependency to make it functional.. and few more .. this is well known as SOLID principle

For those who are not aware of this, SOLID is an acronym for the first 5 principles of object-oriented design:

  • Single Responsibility Principle
  • Open Closed Principle
  • Liskov Substitution Principle
  • Interface Segregation Principle
  • Dependency Inversion Principle

Where Design Pattern - is much about how you want's to define/maintain the coding standard in the application.. how to simplify application's execution flow in standard way .. so that it can maintain easily ..

In example below .. one design pattern is defined.. it is about how every developer should create an object..

//Register   builder.RegisterType<ConsoleOutput>().As<IOutput>();                           builder.RegisterType<TodayWriter>().As<IDateWriter>();  Container = builder.Build();    //Create instance  var writer1 = Container.Resolve<IOutput>();                  writer1.Write("HelloWorld");     var writer2 = Container.Resolve<IDateWriter>();                 writer2.WriteDate();  

The architect want's to create a design pattern where every developer must create an interface on the top of the class.. and the interface and class must register in factory to create an instance ..because the architect wants some statistical report like how many classes(Business object) are registerd or how many objects are created to complete a single module(It can be achieved easily now by putting some code in-side 'RegisterType' and 'Resolve' funtions of factory) ..

So, it's might be quite clear now that design patterns and OOP are very different aspect

Can we believe that if someone who knows Design Patterns would definitely be an OOP expert? - It is expected to be ... but not mandatory!!


Object Oriented Programming is itself a design pattern.

Note:If u also have question or solution just comment us below or mail us on toontricks1994@gmail.com
Next Post »