Design Patterns

Creational Patterns

Abstract Factory Builder Factory Method Prototype Singleton

Iterator Design Pattern (Behavioral)

Accesses the elements of an object sequentially without exposing its underlying representation. Is a behavioral design pattern that lets you traverse elements of a collection without exposing its underlying representation (list, stack, tree, etc.). "Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation." https://refactoring.guru/design-patterns/iterator https://springframework.guru/gang-of-four-design-patterns/iterator-pattern/

Structural Patterns

Adapter Bridge Composite Decorator Facade Flyweight Proxy

State Design Pattern (Behavioral)

Allows an object to alter its behavior when its internal state changes. A behavioral design pattern that lets an object alter its behavior when its internal state changes. It appears as if the object changed its class. https://refactoring.guru/design-patterns/state https://www.youtube.com/watch?v=MGEx35FjBuo&list=PLhkg-R66TRTV1-mDPLQ1HL7Wk9dGRBgSd&index=7 https://springframework.guru/gang-of-four-design-patterns/state-pattern/

Decorator Design Pattern (Structural)

Allows for an object's behavior to be extended dynamically at run time. A structural design pattern that lets you attach new behaviors to objects by placing these objects inside special wrapper objects that contain the behaviors. https://refactoring.guru/design-patterns/decorator https://www.youtube.com/watch?v=j40kRwSm4VE&list=PLhkg-R66TRTV1-mDPLQ1HL7Wk9dGRBgSd&index=4 https://springframework.guru/gang-of-four-design-patterns/decorator-pattern/

Adapter Design Pattern (Structural)

Allows for two incompatible classes to work together by wrapping an interface around one of the existing classes. A structural design pattern that allows objects with incompatible interfaces to collaborate. The Adapter acts as a wrapper between two objects. It catches calls for one object and transforms them to format and interface recognizable by the second object. https://refactoring.guru/design-patterns/adapter https://www.youtube.com/watch?v=qG286LQM6BU&list=PLhkg-R66TRTV1-mDPLQ1HL7Wk9dGRBgSd https://springframework.guru/gang-of-four-design-patterns/adapter-pattern/

Mediator Design Pattern (Behavioral)

Allows loose coupling between classes by being the only class that has detailed knowledge of their methods. A behavioral design pattern that lets you reduce chaotic dependencies between objects. The pattern restricts direct communications between the objects and forces them to collaborate only via a mediator object. https://refactoring.guru/design-patterns/mediator https://www.youtube.com/watch?v=8DxIpdKd41A&list=PLhkg-R66TRTV1-mDPLQ1HL7Wk9dGRBgSd&index=3 https://springframework.guru/gang-of-four-design-patterns/mediator-pattern/

Strategy Design Pattern (Behavioral)

Allows one of a family of algorithms to be selected on-the-fly at run-time. A behavioral design pattern that lets you define a family of algorithms, put each of them into a separate class, and make their objects interchangeable. https://refactoring.guru/design-patterns/strategy https://www.youtube.com/watch?v=-NCgRD9-C6o&list=PLhkg-R66TRTV1-mDPLQ1HL7Wk9dGRBgSd&index=17 https://springframework.guru/gang-of-four-design-patterns/strategy-pattern/

Abstract Factory Design Pattern (Creational)

Allows the creation of objects without specifying their concrete type. A creational design pattern that lets you produce families of related objects without specifying their concrete classes. https://refactoring.guru/design-patterns/abstract-factory https://www.youtube.com/watch?v=xbjAsdAK4xQ&list=PLhkg-R66TRTV1-mDPLQ1HL7Wk9dGRBgSd&index=9 https://springframework.guru/gang-of-four-design-patterns/abstract-factory-design-pattern/

The Expert (GRASP design pattern)

Bloated controllers imply tight coupling in our system, which is bad. The Expert Pattern solves this by encapsulating information about a task into a distinct class.

Behavioral Patterns

Chain of Responsibility Command Interpreter Iterator Mediator Memento Observer State Strategy Template Method Visitor

CRUD

Create, Read, Update, Delete

Prototype Design Pattern (Creational)

Creates a new object from an existing object. A creational design pattern that lets you copy existing objects without making your code dependent on their classes. https://refactoring.guru/design-patterns/prototype https://www.youtube.com/watch?v=AFbZhRL0Uz8&list=PLhkg-R66TRTV1-mDPLQ1HL7Wk9dGRBgSd&index=16 https://springframework.guru/gang-of-four-design-patterns/prototype-pattern/

Command Design Pattern (Behavioral)

Creates objects which encapsulate actions and parameters. A behavioral design pattern that turns a request into a stand-alone object that contains all information about the request. This transformation lets you pass requests as a method arguments, delay or queue a request's execution, and support undoable operations. https://refactoring.guru/design-patterns/command https://www.youtube.com/watch?v=7Pj5kAhVBlg&list=PLhkg-R66TRTV1-mDPLQ1HL7Wk9dGRBgSd&index=11 https://springframework.guru/gang-of-four-design-patterns/command-pattern/

Factory Design Pattern (Creational)

Creates objects without specifying the exact class to create. Is a creational design pattern that provides an interface for creating objects in a superclass, but allows subclasses to alter the type of objects that will be created. https://refactoring.guru/design-patterns/factory-method https://www.youtube.com/watch?v=ub0DXaeV6hA&list=PLhkg-R66TRTV1-mDPLQ1HL7Wk9dGRBgSd&index=14 https://springframework.guru/gang-of-four-design-patterns/factory-method-design-pattern/

Bridge Design Pattern (Structural)

Decouples an abstraction so two classes can vary independently. Design pattern that lets you split a large class or a set of closely related classes into two separate hierarchies—abstraction and implementation—which can be developed independently of each other. https://refactoring.guru/design-patterns/bridge https://springframework.guru/gang-of-four-design-patterns/bridge-pattern/

Template Method Design Pattern (Behavioral)

Defines the skeleton of an algorithm as an abstract class, allowing its sub-classes to provide concrete behavior. A behavioral design pattern that defines the skeleton of an algorithm in the superclass but lets subclasses override specific steps of the algorithm without changing its structure. https://refactoring.guru/design-patterns/template-method https://www.youtube.com/watch?v=aR1B8MlwbRI&list=PLhkg-R66TRTV1-mDPLQ1HL7Wk9dGRBgSd&index=5 https://springframework.guru/gang-of-four-design-patterns/template-method-pattern/

Chain of Responsibility Design Pattern (Behavioral)

Delegates commands to a chain of processing objects. A behavioral design pattern that lets you pass requests along a chain of handlers. Upon receiving a request, each handler decides either to process the request or to pass it to the next handler in the chain. https://refactoring.guru/design-patterns/chain-of-responsibility https://www.youtube.com/watch?v=jDX6x8qmjbA&list=PLhkg-R66TRTV1-mDPLQ1HL7Wk9dGRBgSd&index=8 https://springframework.guru/gang-of-four-design-patterns/chain-of-responsibility-pattern/

SOLI 'D'

Dependency Inversion Principle (DIP) States that high-level modules/classes should not depend on low-level modules/classes. Instead, both should depend upon abstractions. Secondly, abstractions should not depend on details; details should depend upon abstractions.

Singleton Design Pattern (Creational)

Ensures only one instance of an object is created..."a class which can only be instantiated once, and a global point of access to that instance is provided." Lets you ensure that a class has only one instance, while providing a global access point to this instance. https://refactoring.guru/design-patterns/singleton https://springframework.guru/gang-of-four-design-patterns/singleton-design-pattern/

'S' OLID

Every module, class, or function in a computer program should have responsibility for a single part of that program's functionality. Also, they should encapsulate that part, and their services should be narrowly aligned with that responsibility.

ViewModel

Exposes the data stream associated with the view. It also acts as a link between the model and the view.

Functional programming

Functional programming, as opposed to imperative programming, is a pure functional approach to problem solving. Functional programming is a form of declarative programming. Languages that fit this description include Scheme, Haskell, LISP, Racket, and F#. a functional approach involves composing the problem as a set of functions to be executed. You define carefully the input to each function, and what each function returns. Then your program is essentially a composition of functions that describe the transformation of input data. There are no loops. Every time you'd need a loop in Imperative programming, you use recursion to reach your goal. There is no variables, but constants. The use of immutable data structures is strongly encouraged in FP In pure Functional languages, there can't be direct side-effects on peripherals. Monads are responsible for managing any side-effects. A Monad is a special type that wraps a value and abstracts the necessary side-effects for manipulating the external world.

Imperative Programming

Imperative programming, as opposed to functional programming, is a paradigm in programming that is often referred to as procedural, where a developer writes code that describes in exacting detail the steps that the computer must take to accomplish the goal. Most of the mainstream programming languages, such as C++, Java, and Python, are considered imperative languages. you write code that tell the computer what to do step by step to accomplish the goal. You use variables to store state and you can access this state a mutate it inside functions, loops, and conditional statements.

Interpreter Design Pattern (Behavioral)

Implements a specialized language. Interpreter pattern is used to defines a grammatical representation for a language and provides an interpreter to deal with this grammar. Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language. https://www.geeksforgeeks.org/interpreter-design-pattern/ https://springframework.guru/gang-of-four-design-patterns/interpreter-pattern/

How does n-tier differ from MVC (Model-View-Controller)?

In model-view-controller, the physical structure of the project is abstracted while in the n-tier architecture all the layers are visible and could be configured in a way that developer wants.

S 'O' LID

In simple words, one module/class should be developed in such a way that it allows its behavior to be extended without needing to alter its source code. So, instead of changing the existing functionality, create new derived classes and leave the original class implementation as it is.

Layered Architecture (n-tiered pattern)

Industry standard way of creating applications to work on a network. Layered architecture allows the application developer to make changes in only one layer instead of the whole program.

* Observer Design Pattern (Behavioral)

Is a publish/subscribe pattern which allows a number of observer objects to see an event. A behavioral design pattern that lets you define a subscription mechanism to notify multiple objects about any events that happen to the object they're observing. https://refactoring.guru/design-patterns/observer https://www.youtube.com/watch?v=wiQdrH2YpT4&list=PLhkg-R66TRTV1-mDPLQ1HL7Wk9dGRBgSd&index=13 https://springframework.guru/gang-of-four-design-patterns/observer-pattern/

Controller

It is Activity/Fragment. It communicates with the line of sight and the model. It receives user input from the View / REST service. Get the data from the process request model and pass it to the view.

Model

It is the business logic and data state. We use the model to retrieve and manipulate data, communicate with controllers, interact with databases, and update views.

Presenter

It takes data from the model and applies UI logic to determine what we should display to the user. It is helpful as it manages the view's state and takes action as per the user input notifications from the view.

SO 'L' ID

Liskov Substitution Principle (LSP) The LSP is a Substitutability principle in OOP (Object-Oriented Programming). The third SOLID principle states that if S is a subtype of T, then objects of type T should be replaced with objects of type S. So, if we can successfully replace the object/instance of a parent class with an object/instance of the child class, without affecting the behavior of the base class instance, then we are following LSP.

MVC, MVP, and MVVM

MVC: The Model View Controller architecture tightly couples the view and the model components of the architecture. We can use it suitably for small-scale projects only. The modularity and the single responsibility feature can't be applicable here. MVP: This software architecture has a dependent user interface as it uses the presenter to act as a link between the view and the model. We can use it for simple as well as complex projects. The modularity and the single responsibility feature are applicable here. MVVM: MVVM implements data binding and allows easy separation of the model and the view. This architecture model must only be used for complex projects. This architecture supports the modularity and single responsibility feature.

Proxy Design Pattern (Structural)

Provides a placeholder interface to an underlying object to control access, reduce cost, or reduce complexity. A structural design pattern that lets you provide a substitute or placeholder for another object. A proxy controls access to the original object, allowing you to perform something either before or after the request gets through to the original object. https://refactoring.guru/design-patterns/proxy https://www.youtube.com/watch?v=cHg5bWW4nUI&list=PLhkg-R66TRTV1-mDPLQ1HL7Wk9dGRBgSd&index=6 https://springframework.guru/gang-of-four-design-patterns/proxy-pattern/

Facade Design Pattern (Structural)

Provides a simple interface to a more complex underlying object. "Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use." A structural design pattern that provides a simplified interface to a library, a framework, or any other complex set of classes. https://refactoring.guru/design-patterns/facade https://springframework.guru/gang-of-four-design-patterns/facade-pattern/

Memento Design Pattern (Behavioral)

Provides the ability to restore an object to its previous state. A behavioral design pattern that lets you save and restore the previous state of an object without revealing the details of its implementation. https://refactoring.guru/design-patterns/memento https://www.youtube.com/watch?v=jOnxYT8Iaoo&list=PLhkg-R66TRTV1-mDPLQ1HL7Wk9dGRBgSd&index=2 https://springframework.guru/gang-of-four-design-patterns/memento-pattern/

REST

REpresentational State Transfer

Flyweight Design Pattern (Structural)

Reduces the cost of complex object models. A structural design pattern that lets you fit more objects into the available amount of RAM by sharing common parts of state between multiple objects instead of keeping all of the data in each object. https://refactoring.guru/design-patterns/flyweight https://springframework.guru/gang-of-four-design-patterns/flyweight-pattern/ https://www.youtube.com/watch?v=0vV-R2926ss&list=PLhkg-R66TRTV1-mDPLQ1HL7Wk9dGRBgSd&index=12

SOLID

S - Single Responsibility Principle (SRP) O - Open-Close Principle (OCP) L - Liskov Substitution Principle (LSP) I - Interface Segregation Principle (ISP) D - Dependency Inversion Principle (DIP)

Builder Design Pattern (Creational)

Separate the construction of a complex object from its representation so that the same construction process can create different representations. That lets you construct complex objects step by step. The pattern allows you to produce different types and representations of an object using the same construction code. https://refactoring.guru/design-patterns/builder https://springframework.guru/gang-of-four-design-patterns/builder-pattern/

Visitor Design Pattern (Behavioral)

Separates an algorithm from an object structure by moving the hierarchy of methods into one object. A behavioral design pattern that lets you separate algorithms from the objects on which they operate. https://refactoring.guru/design-patterns/visitor https://www.youtube.com/watch?v=pL4mOUDi54o&list=PLhkg-R66TRTV1-mDPLQ1HL7Wk9dGRBgSd&index=15 https://springframework.guru/gang-of-four-design-patterns/visitor-pattern/

Composite Design Pattern (Structural)

Takes a group of objects into a single object.. "Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly." A structural design pattern that lets you compose objects into tree structures and then work with these structures as if they were individual objects. https://refactoring.guru/design-patterns/composite https://springframework.guru/gang-of-four-design-patterns/composite-pattern/

The Controller (GRASP design pattern)

The Controller is responsible for handling the requests of actors. The Controller is the middle-man between your user clicking "Send" and your back-end making that happen. The Controller knows how to interpret the actions of user-interfaces, and how to connect those actions to behaviours in your system.

The Creator (GRASP design pattern)

The Creator takes the responsibility of creating certain other objects. There are a number of reasons why a class may take the responsibility of creating another. The Creator might have information on how to create said object, or it might be the class that uses the object most closely.

SOL 'I' D

The ISP states that "Clients should not be forced to implement any methods they do not use. Rather than one fat interface, numerous little interfaces are preferred, based on groups of methods, with each interface serving one submodule." That definition can be split into two parts: No class should be forced to implement any interface method(s) that it does not use. Rather than creating large interfaces, create multiple smaller interfaces to allow clients to focus on the methods that are relevant to them.

Model View Presenter Architecture

The MVP pattern overcomes the challenges of MVC and provides an easy way to structure your project code. MVP is popular because it gives modularity, testability, and a cleaner and more maintainable codebase. It helps us to improve the presentation logic of the code.

Model-View-ViewModel Pattern

The MVVM pattern shares some similarities with the MVP (Model-View-Presenter) design pattern in that the ViewModel inherits the role of the presenter. We address the shortcomings of the MVP pattern by MVVM. This model suggests separating the data presentation logic (view or UI) from the core business logic part of the application. ViewModel serves as the glue between the View and the Model. It wraps the data from the Model and makes it friendly for being presented and modified by the view.

Model View Controller Architecture

The Model View Controller design architecture splits your code into three parts- Model, View, and the Controller. We divide the code into the following three parts as per the given details:

View

Views determine what the user sees in an application. User Interface has HTML/CSS/XML. It sometimes communicates with the controller and sometimes interacts with the model as well. It passes some dynamic views through the controller.

business layer

also known as the business logic layer (BLL) or domain logic layer. This is where the logical part of the application happens like calculations, CRUD (create-read-update-delete) operations, data analysis, etc.

application layer

also known as the service layer or GRASP controller layer.

Pure functions

can be evaluated in any order, the result is always the same. Therefore, pure functions calls can be run in parallel.

GRASP

design patterns are a set of design patterns that came after the original Gang of Four book that many of you might be familiar with. GRASP stands for General Responsibility Assignment Software Patterns. These patterns, as the name suggests, aim primarily to answer the question: "Who does what?"

First-class functions

functions that can be treated like any other value--being passed as arguments into other function, returned from functions, placed into data structures as so on.

* N-Tier architecture

multi-tier architecture since the software is separated processing, data management, and presentation layers are differentiated logically and structurally. The N here represents a number like 2,3,4,5... The most common one is the 3-tier. Scalability — You can separate tiers without affecting the other tiers and then scale each one properly. Data Integrity — Cascading effects are prevented, and maintenance becomes easier. One may change the code without affecting the data. Reusability — Different layers could be used in different projects or in the same project you may use the same layer in different places. For instance, you might want to write extensions to your projects and if you want to use them in another project Secure— You can secure the layers without affecting the other layers.

3-Tier Architecture

presentation layer, the application layer, and the data access layer.

presentation layer

the layer of UI (user interface) or view layer

data access layer

where the entities live and it is simply a model of the database like in the Model-View-Controller pattern. This is actually the reason why we call it a model since it is the model of the database.

Closures

A closure is the association of a function code with a set of definitions and bindings from the lexical scope (an enclosed environment). Closures have access to the outer function's variable even after the outer function returns: The inner function still has access to the outer function's variables even after the outer function has returned.