Design Principle

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

Design Principle
Program to an interface, not an implementation

Design Principle
Favor composition over inheritance

The Open-Closed Principle

Design Principle
Classes should be open for extension, but closed for modification.

Feel free to extend our classes with any new behavior you like. If your needs or requirements
change (and we know they will), just go ahead and make your own extensions.
Sorry, were closed. Thats right; we spent a lot of time getting this code correct and bug
free, so we cant let you alter the existing code. It must remain closed to modification.

When I inherit behavior by sub classing, that behavior is set statically at compile time. In addition, all
subclasses must inherit the same behavior. If however, I can extend an objects behavior through
composition, then I can do this dynamically at runtime.

By dynamically composing objects, I can add new functionality by writing new code rather than
altering existing
code.

The Open-Closed Principle usually introduces new levels of abstraction, which adds complexity to our
code. You want to concentrate on those areas that are most likely to change in your designs and apply
the principles there

The Dependency Inversion Principle

Design Principle
Depend upon abstractions. Do not depend upon concrete classes

At first, this principle sounds like Program to an interface, not an implementation

however this principle makes even stronger statement about abstraction
It suggests that our high level components should not depend on our low level
components; rather, they should both depend on abstractions

Below guidelines can help you avoid object oriented design that violate the
dependency inversion principle

No Variable should hold a reference to a concrete class

No Class should derive from a concrete class
No method should override an implemented method of any of its base classes
Design Principle
Principle of Least knowledge talk only to your immediate friends

It guides us to reduce the interactions between objects to just a few close friends. It
means 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 us from creating designs that have a large 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

The principle tell us that we should only invoke the 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

Design Principle
Dont call us, well call you.

It guides us a way to prevent dependency rot. It happens when high level

components depending on low-level component depending on sideways component
depending on low level components and so on.
With this principle, we allow low level components to hook themselves into a
system, but the high level components determine when they are needed and how.

Design Principle
A class should have only one reason to change

With this principle, we allow low level components to hook themselves into a
system, but the high level components determine when they are needed and how.