Skip to content

Latest commit

 

History

History
229 lines (192 loc) · 9.58 KB

README.md

File metadata and controls

229 lines (192 loc) · 9.58 KB
Raw

Refactoring

Remodelling overall app so that new features can fit up or you can optimize overall app for achieving readability, extensibility, ...

OOPS

Abstraction

Display only essential information and hide details

Encapsulation

Binding data and behaviour into single unit

Polymorphism

Perform same thing in different ways

Inheritance

Sub class inherits properties and methods from base class

Relations b/w classes

1. Association
    - Biderictional relationship b/w classes
    - 1 to *
    - * to 1
    - 1 to 1
2. Composition
    - Part cannot exist without Whole
3. Aggregation
    - Whole-Part relationship
    - Class contains object of another class but contained object can exist independently
4. Generatlization
    - IS A relationship
    - like inheritance

SOLID

  • conventions
  • create maintainable, extensible, flexible s/w
  • SOLID principle provides/helps
    • Testing
    • Modularity
    • Coupling

Single Responsibility Principle

  • A class should have only one reason/responsibility to change.
  • class adheres to SRP
    • Identify responsibility
    • Separation of concerns
  • Scenarios that violate SRP
    • God class
      • split into smaller classes handling single reposibility

Open-Closed Principle

  • A class should be open for extension but closed for modification

Liskov-substitution

  • Base/Derieved class pointer should be interchangeable
  • object of super class should be easily replecable with object of subclass
  • subclass should preserve behavior of superclass
  • requires
    • Behavorieal Presentation

Interface seggregation

  • A class should not "forced to" implement interfaces or implement interface methods which it does not require
  • remove/avoid unnecessary dependencies
  • flexibility/dependencies
  • What should not do
    • Avoid bloating

Dependency Inversion

  • Use interface/abstract class for dependency rather concrete implementation
  • loose coupling
  • Flexible, easier to test, maintable
Inversion of control

Design Patterns

- Typical solutions to commonly occurring problems in software design.
- Blueprints that can be used to customize to solve a particular design problem in your code.
- Well known way of solving a well known problem. (Template for solving problem)
- Simpler communication in one phrase

Object Oriented Design Patterns

  • Creational

    1. Builder

      • Seperate construction of object from its representation.
      • avoiding a constructor with numerous parameters
      • Perform validations
      • Creation of object is easier and resillient
      • Director - any class orchestrates the construction process using builder interface to construct actual objects.
      • Final objects return to client by Director
      • complexity
      • enhancement
      • loose coupling
      • extensibility

    2. Factory

      • Segregating the logic for creating the object wherever required

    3. Prototype

      • Cloning of the object (based on the existing ones)
      • Document Management system (clone document)
      • DB entity (clone db entity)
      • configuration management

    4. Singleton

      • Single object getting created throughout the scope of execution.
      • Can achieve thread safety

    5. Abstract Factory

      • Interface for Factory of similar objects without concrete classes

    6. Factory Method

  • Behavioral

    1. Strategy

    2. Chain of Responsibility

      • Allows an object to pass through a chain of handler.
      • Handlers will decide either to process or pass the request to next handler.

    3. Command

      • Required when want to convert Actions/Requests/Methods into first class entity(object)
      • Encapsulates the requests as an object which allows parameterization of client

    4. Observer

      • For notifications
      • Observer
      • Observable
      • One to Many relationship
      • change in 1 leads to chnage in multiple
      • without making tightly coupled
      • dynamic chnages in number of observers and their types
      • when to use
        • Flexibilty & decoupling
        • Real-Time updates
        • Dynamic Relationships

    5. Visitor

    6. Memento

    7. Pipes Filters

    8. Template Method

    9. Iterator

    10. Null Object

    11. Strategy

      • selecting algorithm or behaviour at runtime
      • encourages composition over inheritance

    12. State

      • allow state change when behaviour is going to be chnaged
      • encapsulation of the behavior associated with the state
      • Behavior of a particular classes and entities
      • deals with conditional aspects
      • context - mantains current state of the object

  • Structural

    1. Adapter

      • Allows objects with incompatible interfaces to work together.
      • Acting as a bridge b/w incompatible interfaces
      • "adpats" the interface of one class to match interface of another class
      • usability
        • Integrate with 3rd party libraries or APIs
        • Legacy System Interoperability
        • Interface Standardization in Large Systems

    2. Decorator

      • add additional responsibilities dynamically
      • used with Inheritance
      • used for Open Closed Principle
      • maintains interface to pizza object
      • Structure
        • Component
        • ConcreteComponent
        • Decorator (Wrapper along with Reference to component)
        • Concrete Decorator
      • example: Pizza, Coffee, Premium subscription

    3. Proxy

      • Placeholder to control and access another object without modifying the code
      • lazy loading of object or initialization on demand
      • control access. example security construct
      • Usage & Usability
        • Adding layer of control over real object
        • lazy loading of expensive operation
        • access control from the object
      • Use cases
        • Caching
        • Logging
        • Login

    4. Bridge

    5. Flyweight

    6. Facade

      • Way to hide complexity of a subsystem.
      • "Do not expose what is not necessary" principle
      • loose coupling
      • high level user-friendly interface
      • encourages encapsulation
      • separation of concerns so that client have easiness to use the subsystem

Enums

Use when dealing FINITE set of things

Manager

POJO manager, if required

Status

- as a enum

Inheritance vs Composition

- In inheritance - bound to use everything as a part of subclass
- In composition - it is providing flixibility, encapsulation, easily extensible, easily modifiable, decoupled
- Composition avoids Diamond problem

Favour Composition Over Inheritance (FOI Principle)

Clean Code Practices

1.  Names of variables
2.
3.  Comments
     eg. counter++; // Adding 1 to counter   X
         counter++; // Incrementing counter
4.  Cormatting/Indentation
5.  Avoiding Magic numbers
6.  Exception
7.  Duplicate code avoiding (DRY)
8.  Single Responsibility principle
9.  Methods/Codebase should be small
10. Classes should be small
11. Clean/readable Unit test + cover all scenarios (very important)