What's the Difference Between Design Patterns and Design Principles

What's the difference between design patterns and design principles?

Design Principles:

Design principles are core abstract principles that we are supposed to follow while designing software. Remember they aren't concrete - rather abstract. They can be applied in any language, on any platform regardless of the state as long as we are within the permissible conditions.

Examples:

• Encapsulate what varies.
• Program to interfaces, not to implementations.
• Depend upon abstractions. Do not depend upon concrete classes.

Design Patterns:

They are solutions to real-world problems that pop up time and again, so instead of reinventing the wheel, we follow the design patterns that are well-proven, tested by others, and safe to follow. Now, design patterns are specific; there are terms and conditions only in which a design pattern can be applied.

Examples:

• Singleton Pattern ( One class can only have one instance at a time )

• Adapter Pattern ( Match interface of different classes )

The following analogy will help you understand the difference better:

Principle: We should teach others in order to educate ourselves as well as others, and overall make our nation a progressive nation.

Pattern: In our country, each medical doctor graduate is supposed to teach 6 months in a far-away village to complete his/her degree.

What's the difference between design patterns and architectural patterns?

It requires a detailed explanation but I will try to sketch the differences to best of my knowledge.

Patterns are distilled commonality that you find in programs. It allows us to deconstruct a large complex structure and build using simple parts. It provides a general solution for a class of problems.

A large complex software goes through a series of deconstruction at different levels. At large level, architectural patterns are the tools. At smaller level, design patterns are the tools and at implementation level, programming paradigms are the tools.

A pattern can occur at very different levels. See Fractals. Quick sort, Merge sort are all algorithmic patterns for organizing a group of elements in a order.

For a most simplistic view:

• Programming paradigms - specific to programming language
• Design patterns - solves reoccurring problems in software construction
• Architectural patterns - fundamental structural organization for software systems

Idioms are paradigm-specific and language-specific programming techniques that fill in low-level details.

Design patterns are usually associated with code level commonalities. It provides various schemes for refining and building smaller subsystems. It is usually influenced by programming language. Some patterns pale into insignificance due to language paradigms.
Design patterns are medium-scale tactics that flesh out some of the structure and behavior of entities and their relationships.

While architectural patterns are seen as commonality at higher level than design patterns.
Architectural patterns are high-level strategies that concerns large-scale components, the global properties and mechanisms of a system.

How are patterns obtained?
Through:

1. re-use,
2. classification
3. and finally abstraction to distill the commonality.

If you have followed the thoughts laid above. You will see that Singleton is a "design pattern" while MVC is one of the "architectural" pattern to deal with separation of concerns.

Try reading on:

1. http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science)
2. http://en.wikipedia.org/wiki/Design_pattern
3. http://en.wikipedia.org/wiki/Anti-pattern

Can't seem to understand SOLID principles and design patterns

I've taken a class in college that spent two weeks around design patters, and read the Gang of Four book to no avail. Understanding what each pattern served for and how to use them to fit my problems was very hard for me, a developer that didn't have much experience in OO programming.

The book that really made it click for me was Head First Design Patterns. It starts by showing a problem, different approaches the developers considered, and then how they ended up using a design pattern in order to fix it. It uses a very simple language and keeps the book very engaging.

Design patterns end up being a way to describe a solution, but you don't have to adapt your classes to the solution. Think of them more as a guide that suggest a good solution to a wide array of problems.

Let's talk about SOLID:

1. Single responsibility. A class should have only one responsibility. That means that for example, a Person class should only worry about the domain problem regarding the person itself, and not for example, its persistence in the database. For that, you may want to use a PersonDAO for example. A Person class may want to keep its responsibilities the shortest it can. If a class is using too many external dependencies (that is, other classes), that's a symptom that the class is having too many responsibilities. This problem often comes when developers try to model the real world using objects and take it too far. Loosely coupled applications often are not very easy to navigate and do not exactly model how the real world works.
2. Open Closed. Classes should be extendible, but not modifiable. That means that adding a new field to a class is fine, but changing existing things are not. Other components on the program may depend on said field.
3. Liskov substitution. A class that expects an object of type animal should work if a subclass dog and a subclass cat are passed. That means that Animal should NOT have a method called bark for example, since subclasses of type cat won't be able to bark. Classes that use the Animal class, also shouldn't depend on methods that belong to a class Dog. Don't do things like "If this animal is a dog, then (casts animal to dog) bark. If animal is a cat then (casts animal to cat) meow".
4. Interface segregation principle. Keep your interfaces the smallest you can. A teacher that also is a student should implement both the IStudent and ITeacher interfaces, instead of a single big interface called IStudentAndTeacher.
5. Dependency inversion principle. Objects should not instantiate their dependencies, but they should be passed to them. For example, a Car that has an Engine object inside should not do engine = new DieselEngine(), but rather said engine should be passed to it on the constructor. This way the car class will not be coupled to the DieselEngine class.

Difference between the design pattern and anti-pattern

Simple Difference would be:

Design Patterns:

Solutions which are productive and efficient and are developed by Software Engineers over the years of practice and solving problems.

Anti Patterns:

Known solutions which are actually bad or defective to certain kind of problems.

From Wikipedia:

An anti-pattern is a common response to a recurring problem that is
usually ineffective and risks being highly counterproductive.[1][2]
The term, coined in 1995 by Andrew Koenig,[3] was inspired by a book,
Design Patterns, which highlights a number of design patterns in
software development that its authors considered to be highly reliable
and effective.

The term was popularized three years later by the book AntiPatterns,
which extended its use beyond the field of software design to refer
informally to any commonly reinvented but bad solution to a problem.
Examples include analysis paralysis, cargo cult programming, death
march, groupthink and vendor lock-in.

Example of some anti patterns:

1. https://javaantipatterns.wordpress.com/
2. https://sourcemaking.com/antipatterns

Hope this makes sense.

Connection between GoF Design Patterns and SOLID

SOLID principles are applied in most of GoF's design patterns.

• S: Single responsability principle: the classes that are part of the
  DP, have only one responsability
• O: Open/Closed principle: it is easy
  to extend with new functionality, for example the strategy pattern
  allows you to implement an additional algorithm without having to
  change the other classes that contain other algorithms
• Liskov Substitution Principle: also applies to strategy for instance

Design Principles, Best Practices and Design Patterns for C (or Procedural Programming in general)?

Information hiding - as espoused by Parnas (Software Fundamentals).

Careful management of headers and visibility:

• Everything in a source file that can be hidden from the outside world should be; only the documented external interface should be exposed.
• Everything that is exposed is declared in a header.
• That header is used where the functionality is needed (and where it is defined).
• The header is self-contained - when you need it, you use it, and you don't have to fret about 'what other headers do I also have to include' because the header ensures it works by including anything it needs to make it work.

• The header is self-protected - so it does not matter if it is included multiple times.

  #ifndef HEADER_H_INCLUDED
  #define HEADER_H_INCLUDED
  ...rest of header contents, including other #include lines if necessary
  #endif /* HEADER_H_INCLUDED */
  

• Design sets of functions to work on 'objects' (usually structures) - and use those functions rather than poking around the innards of the structure in the code that is using it. Think of it as self-imposed encapsulation.

What is the Difference between GOF and GRASP design patterns

GOF are patterns i.e. proven design solutions to recurring problems. GRASP are principles and are not tied to any specific problem domain hence true in any scenario

---

Related Topics