The Software Design Principles

Let's first list down these principles that were exposed(and followed) by the pattern-experts and the software-architects world-wide.

1. Encapsulate what varies.
2. Program to Interfaces, not to Implementation.
   
3. Prefer Composition(or Containment) over Inheritance.
4. Strive for a loosely coupled design (lower degree of mutual interdependence between the objects)
   
5. The Open-Closed principle (The design should be open for extension, but closed for modification-requirement)
6. The Dependency Inversion principle (Simply put, instead of client having to fret over the disparate Vendor-specific-APIs, force the vendors to follow a common Interface, which the client can simply program to.)
7. Hollywood-Principle: "Don't call us, we'll call you!" (Let the abstract-class control how to call the methods implemented by the subclasses. Subclasses should have no business deciding the sequence of calls of peer-implemented-methods).
8. The Single Responsibility Principle (The class should have one and only one reason to change).
9. Minimum-Awareness-Principle(Law of Demeter): "Only talk to your immediate friends." (Never call a method on an object you got from another object).
10. The Interface Segregation Principle: (Clients should not be forced to depend on the Interfaces that they don't use)

Now we need to study the contexts in which these priciples work and what happens if we violate them. We'll study various scenarios (problems and patterns used to solve them) and see how these principles are the foci around which the design patterns revolve.