Principle Of Least Knowledge Principle

 Principle of least knowledge - talk only to your immediate friends.

 When you are designing a system, for any object, be careful of the number of classes it interacts with and also how it comes to interact with those classes.

This principle prevents use from creating designs that have a larger number of classes coupled together so that changes in one part of the system cascade to other parts. When you build a lot of dependencies between many classes, you are building a fragile system that will be costly to maintain and complex for others to understand.

How do we do this?
The principle tells us tat we need to make sure that we only invoke methods that belong to.

• The object itself
• Objects passed in as a parameter to the method
• Any object the method creates or instantiates
• Any components of the object.

This sounds kind of stringent doesn't it? whats the harm in calling the method of an object we get back from another call? Well, if we were to do that, then we'd be making a request of another objects sub-part (an increasing the number of object we directly know). In such cases, the principle forces use to ask the object to make the request for us; that way we don't have to know about its component object (and we keep out circle of friends small). for example:

Here's a car class that demonstrates all the ways you can call methods and still adhere to the Principle of Least Knowledge;

 

Open-Closed Principle

Classes should be open for extension, but closed for modification. that is, such an entity can allow its behavior to be extended without modifying its source code.

Open-Closed principle
-Goal is to allow classes to be easily extended to incorporate new behavior without modifying existing code. 

- There are ways of "inheriting" behavior at run-time through composition and
-IT is possible to add multiple new responsibility to objects, through this technique, including responsibilities that were not even thought of by the designer of the super class. and you don't have to touch their code.
-Code should be closed for modification, yet open for extension
-  Takes time and effort to make code this flexible

- must be careful when choosing the areas of code that need to be extend; applying the open-closed principle EVERYWHERE is wasteful and unnecessary and can lead to complex hard to understand code.

Loosely Coupled Principle

Strive for loosely coupled design between objects that interact. (minimal interdependency on other objects)

Loose coupling is an approach to interconnect the components in a system or network so that those components, also called elements, depend on each other to the least extent practicable. Coupling refers to the degree of direct knowledge that one element has of another.

The goal of a loose coupling architecture is to reduce the risk that a change made within one element will create unanticipated changes within other elements. Limiting interconnections can help isolate problems when things go wrong and simplify testing, maintenance and troubleshooting procedures.

-------------------

For example, the Observer pattern provides an object design where the subject(observable) and the observer are loosely coupled.

The only thing the subject knows about the observer is that it implements a certain interface. (the observer interface). it doesn't need to know the concrete class of the observer, what it does or anything else about it.

We can add new observers at any time, because the only thing the subject depends on is a list of objects that implement the observer interface, we can add new observers whenever we want. In face, we can replace any observer at run-time with another observer and the subject will keep purring along. Likewise, we can remove observers at any time.

We never need to modify the subject to add new types of observers. Lets say we have a new concrete class come along that needs to be an observer. We don't need to make any changes to the subject to accommodate the new class type, all we have to do is implement the observer interface in the new class and register as observer. The subject doesn't care; it will deliver notifications to any object that implements the Observer interface.

We can re-use subjects or observers independently of each other. If we have another use for a subject or an observer, we can easily reuse them because the two aren't tightly coupled.

Changes to either the subject or an observer will not affect the other. Because the two are loosely coupled, we are free to make changes to either, as long as the object still meet their obligations to implement the subject or observer interfaces.

Loosely coupled designs allow use to build flexible OO systems that can hand change because they minimize the inter-dependency between objects.

Favor Composition Over Inheritance Principe

Favor composition over inheritance. (Has-a instead of Is-a)

HAS-A can be better than IS-A
Creating systems using composition gives you more flexibility. Not only does it let you encapsulate a family of algorithms into their own set of classes, but it also lets you change behavior at run-time as long as the object you're composing with implements the correct behavior interface. 

Composition is used in many design patterns. 

Program to an interface/abstract class, not an implementation Principle

  Program to an interface/abstract class , not an implementation

The goal here is to keep things flexible, as if things are inflexible, then were going to get into trouble further down the road, especially when we try to extend the application.
The  point here is to exploit polymorphism  by programing to a super-type (interface/abstract class) so that the actual run-time object isn't locked into the code. and we could rephrase "program to a super-type" as "the declared type of the variables should be a super-type, usually an abstract class or interface, so that objects assigned to those variables can be be of any concrete implementation of the super-type,  means the class declaring them doesn't have to know about the actual object types".

 

Encapsulate what varies principle

Identify the aspects of your application that vary and separate them from what stays the same.

 In other words, if you've got some aspect of your code that is changing, say with every new requirement, then you know you've got a behavior that needs to be pulled out and separated from all the stuff that doesn't changes.

Here's another way of thinking about it, take the parts that vary and encapsulate them, so that later you can alter or extend the parts that vary without affecting those that don't

As simple as this concept is, it forms the basis of every design pattern. 

i.e if you have a car base class in a game, and notice that each cars exhaust will make a different noise.

encapsulate this behavior by extracting it out of car class, and class abstract compose an IexhaustNoise interface that exposes a ExhaustNoise() method.

The Facade Pattern

Facade Pattern

 - In this post we are going to look at a pattern that alters an interface, to simplify the interface. Its aptly named the Facade Pattern because this pattern hides all the complexity of one or more classes behind a clean, well lit facade.

Defined

-The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. Facade defines a higher level interface that makes the subsystem easier to use.

Diagrams

 

Bullet Points

• When you need to simplify and unify a large interface or complex set of interfaces, use a Facade.
• A Facade decouples a client from a complex subsystem
• Implementing a Facade requires that we compose the facade with its subsystem and use delegation to perform the work of the Facade.
• You  can implement more then one Facade per subsystem