Design patterns

"general reusable solutions to a commonly occurring problem within a given context in software design".

Design patterns may be viewed as a structured approach to computer programming intermediate between the levels of a programming paradigm and a concrete algorithm.

Design patterns are a great way to describe the culture of a programming language. Design patterns are very language-specific - what is a pattern in one language may be unnecessary in another due to a language feature, or impossible to express due to a missing feature.

If overused, design patterns can add unnecessary complexity to programs. However, they are a great way to share intermediate and advanced level knowledge about a programming language.

Design principles

A brief overview over common design principles

SOLID

• Single Responsibility Principle (SRP):
  A class should only have a single responsibility, that is, only changes to
  one part of the software's specification should be able to affect the
  specification of the class.
• Open/Closed Principle (OCP):
  "Software entities ... should be open for extension, but closed for
  modification."
• Liskov Substitution Principle (LSP):
  "Objects in a program should be replaceable with instances of their subtypes
  without altering the correctness of that program."
• Interface Segregation Principle (ISP):
  "Many client-specific interfaces are better than one general-purpose
  interface."
• Dependency Inversion Principle (DIP):
  One should "depend upon abstractions, [not] concretions."

DRY (Don’t Repeat Yourself)

"Every piece of knowledge must have a single, unambiguous, authoritative
representation within a system"

KISS principle

most systems work best if they are kept simple rather than made complicated;
therefore, simplicity should be a key goal in design, and unnecessary
complexity should be avoided

Law of Demeter (LoD)

a given object should assume as little as possible about the structure or
properties of anything else (including its subcomponents), in accordance with
the principle of "information hiding"

Design by contract (DbC)

software designers should define formal, precise and verifiable interface
specifications for software components, which extend the ordinary definition of
abstract data types with preconditions, postconditions and invariants

Encapsulation

bundling of data with the methods that operate on that data, or the restricting
of direct access to some of an object's components. Encapsulation is used to
hide the values or state of a structured data object inside a class, preventing
unauthorized parties' direct access to them.

Command-Query-Separation(CQS)

“Functions should not produce abstract side effects...only commands
(procedures) will be permitted to produce side effects.” - Bertrand Meyer:
Object-Oriented Software Construction

Principle of least astonishment (POLA)

a component of a system should behave in a way that most users will expect it
to behave. The behavior should not astonish or surprise users

Linguistic-Modular-Units

“Modules must correspond to syntactic units in the language used.” - Bertrand
Meyer: Object-Oriented Software Construction

Self-Documentation

“The designer of a module should strive to make all information about the
module part of the module itself.” - Bertrand Meyer: Object-Oriented Software
Construction

Uniform-Access

“All services offered by a module should be available through a uniform
notation, which does not betray whether they are implemented through storage or
through computation.” - Bertrand Meyer: Object-Oriented Software Construction

Single-Choice

“Whenever a software system must support a set of alternatives, one and only
one module in the system should know their exhaustive list.” - Bertrand Meyer:
Object-Oriented Software Construction

Persistence-Closure

“Whenever a storage mechanism stores an object, it must store with it the
dependents of that object. Whenever a retrieval mechanism retrieves a
previously stored object, it must also retrieve any dependent of that object
that has not yet been retrieved.” - Bertrand Meyer: Object-Oriented Software
Construction