Software Design Principles

 Introduction

In software design, there are many principles and practices which are followed. Few of them are listed below.

SOLID:    

In Object Oriented Programming, SOLID is mnemonic acronym for 5 design principles to make software design more understandable, extensible and maintainable. 

  Single Responsibility Principle: There should never be more than one reason for a class to change. In other words, every class should have only one responsibility. This means for other responsibility create separate class.

Open Closed Principle: Software entities (class, function, module etc.) should be open for extension but closed for modification. Using Inheritance and polymorphism we can achieve this.

Liskov Substitution Principle: Object of a superclass should be replaceable with object of its subclasses without breaking the functionality.

Interface Segregation Principle: No client should be forced to depend on a method if does not use. This means breaks a large interface into smaller and more specific interfaces so that clients will only have to know about the methods that are of interest to them.

Dependency Inversion Principle: The principle states

1. High-level modules should not depend on low-level modules. Both should depend on abstractions (e.g., interfaces).
2. Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.

IOC or Inversion of Control Principles: 

    also known as the Hollywood Principle - "Don't call us, we'll call you"

   IoC inverts the flow of control as compared to traditional control flow. In IoC, custom-written portions of a computer program receive the flow of control from a generic framework. 

A software architecture with this design inverts control as compared to traditional procedural programming: in traditional programming, the custom code that expresses the purpose of the program calls into reusable libraries to take care of generic tasks, but with inversion of control, it is the framework that calls into the custom, or task-specific, code.

Inversion of Control is a key part of what makes a framework different to a library. A library is essentially a set of functions that you can call, these days usually organized into classes. Each call does some work and returns control to the client.

 Dependency Injection: When an object of class X uses specific functionality of object of class Y to perform some action, it is called X depends on Y or X has a dependency on Y. 

Now definition of DI, "Process of creating and passing an object for some other object, it depends on is called Dependency Injection". It is a type of IOC principle.

Object who receives the reference is client. Object which is injected is service and injector, which is responsible for constructing the services and injecting them into the client.

KISS: Keep it simple stupid. The KISS principle states that 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: Don't talk to stranger. There should well defined interface or contract to talk to outside the library, framework etc. It should talk to friends(inside classes of module) not strangers (outside library, framework etc.)