SADP MODULE-01

1. DP – ESSENTIAL ELEMENTS
"Each pattern describes a problem which occurs over and over again in our environment, and then describes the
core of the solution to that problem, in such a way that you can use this solution a million times over, without
ever doing it the same way twice"
1. Pattern Name

• The name of a pattern acts like a "handle" to describe a design problem, its solution, and consequences
in just a word or two.
• It makes it easier to discuss designs and trade-offs with others.
• Example in MVC: "Model-View-Controller (MVC)" is the name of the design pattern. This name
makes it easier to communicate about how to structure user interfaces effectively.
2. Problem
• This explains when and why to use the pattern. It describes the context and the specific challenge.
• Helps you understand the situations where the pattern is applicable.
• Example in MVC: The problem is how to build a user interface where the visual representation (views)
and the core logic or data (model) are separated. This separation ensures flexibility, such as updating one
part without affecting others.
3. Solution
• Describes the components of the pattern (objects, classes, and their relationships) and how they work
together.
• Provides a template for solving a problem without dictating the exact implementation.
• Example in MVC: In MVC:
o Model: Holds the data and core logic.
o View: Displays the data visually (e.g., charts, tables).
o Controller: Manages user input and defines how the interface responds to it.
o They interact via a subscribe/notify mechanism:
▪ The model notifies views of changes.
▪ The views update their display accordingly.
4. Consequences
• These are the results and trade-offs of using the pattern. It might include space, time, flexibility, or
extensibility considerations.
• Helps you evaluate if the pattern is a good fit for your project.
• Example in MVC:
o Benefits: Flexibility to attach multiple views to the same model (e.g., a spreadsheet, pie chart,
and histogram can all show the same data differently). Easy to reuse components.
o Trade-offs: Increased complexity because of the eed to manage interactions between the model,
views, and controllers.

Key Features of MVC in Smalltalk:

• Decoupling:
o Views are independent of the model. The model informs views when data changes, and views
query the model for updated values.
• Flexibility:
 o You can attach different types of views to the same model (e.g., a pie chart or a table for the
same data).
• Nested Views:
o Complex interfaces can be built by nesting views (e.g., a control panel with buttons inside it).
• Dynamic Response:
o The controller determines how the interface responds to user actions. You can change this
response without altering the view's visual design (e.g., switching from buttons to a pop-up
menu).
By following this structure, the MVC design pattern solves the problem of creating flexible, reusable, and
maintainable user interfaces.
2. HOW TO SELECT AND USE THE RIGHT DESIGN PATTERN FOR A PROBLEM?
How to Select and Use the Right Design Pattern for a Problem

1. Identify the Problem: Understand the specific problem you're trying to solve. Focus on challenges such
as tight coupling, frequent redesign needs, or inflexible structures in your application.
Example: If you're dealing with a UI where changes in one component should notify others (e.g., a
dashboard updating when data changes), consider the Observer Pattern.
2. Consider Design Pattern Categories: Patterns are categorized into Creational, Structural, and
Behavioral:
a. Creational: Handle object creation efficiently (e.g., Singleton, Factory).
b. Structural: Deal with the arrangement of classes/objects (e.g., Adapter, Composite).
c. Behavioral: Define communication between objects (e.g., Strategy, Observer).
Example: Use the Factory Method to abstract object creation if you want to avoid specifying concrete
classes.

3. Focus on What Should Be Variable: Instead of worrying about possible changes, identify what needs
to remain flexible. Design patterns help isolate variability.
Example: To vary an algorithm without changing its client, use the Strategy Pattern.
4. Scan Pattern Intent Sections: Review the intent of patterns to see if they match your problem. For
instance, if the problem involves creating objects without specifying their classes, Abstract Factory is a
good match.
5. Check Pattern Interrelationships: Some patterns complement each other. For example, Decorator can
be combined with Composite to handle hierarchical structures with additional functionality.
6. Examine Causes of Redesign: Refer to common redesign triggers such as tight coupling, reliance on
specific implementations, or difficulty extending functionality. Patterns like Adapter or Decorator can
address these issues.

Steps to Use a Design Pattern

1. Read the Pattern Overview: Start with the Applicability and Consequences sections to ensure it's
suitable for your problem.
2. Understand Key Elements: Study the Structure, Participants, and Collaborations to understand how
classes and objects interact in the pattern.
3. Analyze Example Code: Review sample implementations to learn how to apply the pattern practically.
4. Adapt Participant Names: Rename classes and methods in the pattern to suit your application's
context.
 5. Define Classes and Interfaces: Set up the required classes, declare their interfaces, and define their
relationships.
6. Implement Pattern Logic: Write the code to carry out the responsibilities and collaborations defined by
the pattern.
7. Test and Refine: Ensure the pattern integrates well with your application and solves the intended
problem without introducing unnecessary complexity.

3. GENERAL TEMPLATE OF DESIGN PATTERN.

A design pattern is described using a consistent template to provide clarity and uniformity. Below is the general
template:
1. Pattern Name and Classification: Provides a succinct name for the pattern, making it easy to reference
and communicate.
a. Example: Singleton, Factory Method.
2. Intent: Explains what the pattern does and the specific design problem it addresses.
a. Example: "Ensure a class has only one instance and provide a global point of access to it."
3. Also Known As: Lists any alternative names for the pattern.
4. Motivation: Describes a real-world problem scenario and how the pattern solves it.
5. Applicability: Specifies the contexts or situations in which the pattern can be applied.
6. Structure: Provides a graphical representation of the pattern's classes and their relationships (e.g., UML
diagrams).
7. Participants: Lists the classes and objects involved in the pattern and their responsibilities.
8. Collaborations: Explains how the participants work together to fulfill the pattern's intent.
9. Consequences: Describes the results, trade-offs, and potential impact of applying the pattern.
10. Implementation: Offers guidance on implementing the pattern, including pitfalls and language-specific
considerations.
11. Sample Code: Includes snippets of code (in languages like C++ or Smalltalk) to demonstrate the
pattern's implementation.
12. Known Uses: Provides real-world examples where the pattern has been used.
13. Related Patterns: Identifies other patterns related to this one, their differences, and how they can work
together.

This template ensures that each design pattern is well-documented and easy to understand, facilitating its
application in various scenarios.
4. HOW PATTERN CATALOG IS ORGANIZED?

The Pattern Catalog is organized to make it easier to learn and apply design patterns by classifying and
presenting them systematically. Design patterns have different levels of complexity and abstraction, so they
need to be organized. Patterns are classified by two main criteria:

1. Classification by Purpose: What a pattern does.

a. Creational Patterns: Focus on the process of object creation (e.g., Abstract Factory, Builder).
b. Structural Patterns: Deal with the composition of classes or objects (e.g., Adapter, Composite).
c. Behavioral Patterns: Focus on object interactions and responsibilities (e.g., Strategy, Observer).
2. Scope: Where the pattern applies.
a. Class scope: Patterns that focus on relationships between classes and their subclasses,
established at compile-time (static relationships).
 b. Object scope: Patterns that focus on dynamic object relationships, which can be modified at
runtime.
• Class patterns: These handle relationships that are set at compile-time, usually through inheritance.
• Object patterns: These manage relationships that can be changed at runtime, making them dynamic.
• Creational patterns can either defer object creation to subclasses (class patterns) or another object
(object patterns).
• Structural patterns can use inheritance (class patterns) or assemble objects in various ways (object
patterns).
• Behavioral patterns can describe algorithms using inheritance (class patterns) or show how a group of
objects work together to complete a task (object patterns).

5. EXPLAIN DELEGATION AND ITS ADVANTAGES AND DISADVANTAGES.

Delegation is a design principle in object-oriented programming where an object hands off (delegates) a request
or responsibility to another object. Instead of inheriting behavior from a parent class, an object achieves
functionality by referencing another object and forwarding requests to it.
• Example: Instead of making a Window class inherit from Rectangle, the Window class can include a
Rectangle instance and delegate tasks like calculating the area to it. This shifts from an "is-a"
relationship (inheritance) to a "has-a" relationship (composition).
Advantages of Delegation

1. Runtime Flexibility: Behaviors can be composed dynamically at runtime, offering greater flexibility.
a. Example: A Window can dynamically delegate specific responsibilities to different objects based
on the current context.
2. Encapsulation Preservation: Since objects interact through defined interfaces, their internal details
remain hidden, maintaining encapsulation.
3. Reusability: Delegation supports code reuse by combining existing objects' functionality in new ways
without creating complex inheritance hierarchies.
4. Avoids Tight Coupling: Delegation decouples the delegating object from the behavior implementation,
making the system easier to modify and extend.

Disadvantages of Delegation

1. Increased Complexity: Delegation can make the system harder to understand due to the additional
layers of indirection and dynamic composition.
 2. Performance Overhead: Forwarding requests to other objects introduces an additional level of
indirection, which might slightly impact performance.
3. Potential for Overuse: If used excessively, delegation can lead to systems with many small,
interconnected objects, complicating maintenance and debugging.

Use in Design Patterns

Several design patterns leverage delegation:
• State Pattern: An object delegates behavior to a State object based on its current state.
• Strategy Pattern: An object delegates a specific operation to a Strategy object, allowing different
strategies to be swapped dynamically.

6. DESIGN PATTERN & FRAMEWORKS.

Design Patterns and Frameworks are both powerful tools in software development, but they serve different
purposes and operate at different levels of abstraction.

Design Patterns

• Definition: Reusable solutions to common software design problems.

• Focus: Solving specific design issues within a particular context.
• Level of Abstraction: High-level, conceptual descriptions of how to structure code.
• Implementation: Not concrete code, but rather a blueprint or template that can be adapted to various
programming languages and scenarios.
• Examples:
o Creational Patterns: Factory Method, Abstract Factory, Singleton
o Structural Patterns: Adapter, Decorator, Facade
o Behavioral Patterns: Observer, Strategy, Template Method
Frameworks
• Definition: Pre-built, reusable software components that provide a foundation for developing
applications.
• Focus: Providing a complete or partial infrastructure for a specific type of application.
• Level of Abstraction: Lower-level, concrete implementations of common functionalities.
• Implementation: Actual code that can be directly used or extended in a specific programming language.
• Examples:
o Web Frameworks: Django, Ruby on Rails, Spring
o Game Development Frameworks: Unity, Unreal Engine
o Machine Learning Frameworks: TensorFlow, PyTorch

7. DP AVAILABLE IN CATALOG OF DP.

1. Adapter: Converts the interface of a class into another interface clients expect. Lets classes work together that
couldn't otherwise because of incompatible interfaces.

2. Bridge: Decouples an abstraction from its implementation so that the two can vary independently.

3. Command: Encapsulates a request as an object, thereby letting you parameterize clients with different
requests, queue or log requests, and support operations that undoable.
4. Composite: Composes objects into tree structures to represent part-whole hierarchies. Lets clients treat
individual objects and compositions of objects uniformly.

5. Decorator: Dynamically adds responsibilities to objects. Provides a flexible alternative to subclassing for
extending functionality.

6. Facade: Provides a unified interface to a set of interfaces in a subsystem. Defines a higher-level interface that
makes the subsystem easier to use.

7. Factory Method: Defines an interface for creating an object, but lets subclasses decide which class to
instantiate. Let's a class defer instantiation to subclasses.

8. OBJECT ORIENTED KEY CONCEPTS.

1. Central Role of Objects

a. Objects are at the core of object-oriented programming (OOP). Each object contains data and the
operations (methods) that work on that data.
b. Example: Think of a "Car" as an object. It has data like color, brand, and fuel type, and methods
like start(), stop(), and accelerate ().
c. This makes OOP stable and reusable, unlike older process-based systems that required
significant rework when requirements changed.
2. Classes and Classification
a. A class is like a blueprint for creating objects. It defines the structure (data) and behavior
(methods) of objects.
b. Classes help categorize objects, enabling the use of hierarchies, specialization, and
generalization.
c. Example: A "Vehicle" class can have specialized subclasses like "Car" and "Bike" .
3. Abstract Specification of Functionality
a. Abstract classes or interfaces define what an object can do without specifying how.
b. This acts like a "contract" that ensures all implementations follow the same rules, making
systems easier to understand and verify.
c. Example: An interface "Shape" may define methods like draw() and resize(), but each shape
(Circle, Rectangle) implements them differently.
4. Modularity and Encapsulation
a. Modularity means designing systems as independent components. Encapsulation ensures that a
component hides its internal details, exposing only what is necessary.
b. Example: A "Car" module may expose methods like drive() but hide how the engine works
internally.
5. Inheritance and Composition
a. Inheritance: A subclass inherits properties and behaviors from a parent class, making it easier to
reuse and extend functionality.
b. Composition: Objects are composed of other objects, promoting flexibility by combining
functionalities at runtime.
c. Example: A "SportsCar" class might inherit from "Car" (inheritance) and use an "Engine" object
for specific functionality (composition).
6. Extendibility and Adaptability
a. Systems built using OOP can evolve over time. Inheritance and composition enable developers
to modify or extend existing functionality with minimal effort.
 b. Example: A "Car" class can be extended to create "ElectricCar" by adding a battery-specific
feature.
7. Cohesion and Coupling
a. Cohesion: Measures how closely related the tasks within a module are. High cohesion leads to
more reliable and maintainable modules.
b. Coupling: Measures how dependent modules are on each other. Lower coupling allows easier
changes without affecting the entire system.
c. Example: A "Payment" module with clear responsibilities (e.g., processing payments) is
cohesive. It interacts with other modules like "Order" through defined interfaces, minimizing
coupling.
8. Object-Oriented Analysis and Design (OOAD)
a. OOAD provides a step-by-step approach to transitioning from abstract functional requirements
to concrete implementations.
b. Example: Start with identifying "Customer" as a conceptual class. During design, refine it with
attributes like name and methods like placeOrder(). Finally, implement it in code .

Advantages of Object-Oriented Design

• Encourages reuse of code through inheritance and design patterns.
• Enhances modifiability, allowing easier adaptation to new requirements.
• Supports clearer communication and understanding of system designs .

Drawbacks
• Increased complexity due to multiple layers of abstraction.
• Object creation and destruction can add performance overhead.
• Steeper learning curve for developers new to OOP.