This document discusses software design patterns and relationships between classes. It defines what a design pattern is - a common solution to a recurring problem in software design. It categorizes design patterns into creational, structural, and behavioral patterns. It also discusses object-oriented programming principles like inheritance, polymorphism, and encapsulation. Additionally, it explains different types of relationships between classes like inheritance, association, aggregation, and composition. It notes that the Unified Modeling Language (UML) is used to visualize and document design patterns and class relationships.

1. Design Pattern

2. Software Architecture
Pattern :
A common solution and the best practice to solve a reoccurring problem

3. Software developers
encountered many recurring
problems during software
development, after enhanced
and developed those
solutions, they documented
the steps and sequence to
solve those problems in
future, this solution called
software design pattern.

4. Design pattern is a how we can design relation
among classes and objects to solve a general and
repeatable problem in specific context ..
Design pattern :skip the complex hard work and jump
into straight design and plan your work to improve the
quality of the software and reduce development time and
cost .

5. Before start your design pattern you have to know that
OOP Basics :
Inheritance
Polymorphism
Encapsulation
Abstraction
OOP Principles :
Favor composition better than inheritance
Code in interface not an implementation

6. We can classify Design patterns into
Structural (the composition of classes or objects):
– Adapter, Bridge, Composite, Decorator, Façade, Proxy
Behavioral (object interactions):
– Interpreter, Iterator, Mediator,
Creational (object creation):
– Abstract Factory, Builder, Factory Method, Prototype, Singleton

7. UNIFIED MODELING LANGUAGE
(UML)
• Is an application modeling specification
• Is a language for specifying , Virtualizing and documenting the artifacts of
system.
• The primary objective of UML is to simplify the complex software
engineering process
• UML visualize and create artifacts of systems
• Its common language and standard tool to illustrate the design patterns

8. UML and Design pattern

9. Mark Visibility type
+ Public
# Protected
- Private
~ Package
Access Modifiers - Visibility

10. CLASS DIAGRAMS
UML Conventions

11. Inner Class
UML Conventions

12. Use Italic text for the
Abstract class and
methods
Inheritance
Generalization
UML Conventions

13. Interfaces
Realization
dotted Arrow
UML Conventions

14. Methods Throwing Exceptions
UML Conventions

15. Important definitions
•Subclass /child class / derived class:
•Super class/ parent class / Base class:

16. Relationships between Classes
- Inheritance (Generalization) IS A
- Association Has A
- Aggregation – sharing
- Composition – Non sharing

17. • Is-A relationship
• In Is-A relationship one class is obtaining the features of another class by
using inheritance concept with extends keywords.
• Man IS A Human (Man is extends for Human)
All public and protected Methods and attributes in Human will be in Man
• If you change method in Human will effect directly in Man
Relationships between Classes

18. • Has-A relationship
• In Has-A relationship an object of one class is created as data member in another
class the relationship between these two classes is Has-A.
• Man HAS A Relationships with others.
• There is an associations between the Man and the the other could be strong or
weak relationship .Maybe peer to peer relationship or Ownership relationship .
Relationships between Classes

19. Relationships
between
Classes

20. Car
Passenger Driver
EngineGas Station
Vehicle

21. Dependency
Is a relation between two classes, where one class depends on another class
So any change in classes may affect the functionality of the other dependent class.
For example Car and Gas Station, we have Car need to fill oil to start Engine , in this case, Car class is
dependent on the GasStation class. In the future, if any change are made to the GasStation class, it may
result in changes to the Car class.
Relationships between Classes

22. Association
• Association is a structural relationship between two classes where all objects have
their own lifecycle and there is no ownership.
• Let’s take an example of Car and Passenger relationship
Multiple Passengers can associate with a single Car and a single Passenger can
associate with multiple Cars , but there is no ownership between the objects and
both have their own lifecycle. Both can create and delete independently.
• Each Class contains reference to another Class , maybe one-to-one relationship or
one-to-many, many to many ..
Relationships between Classes

23. Aggregation
• Aggregation is a specialized form of Association where all objects have their own lifecycle,
but there is ownership and a child object cannot belong to another parent object.
• Let’s take an example of a Car and Driver Relationship . A single Car cannot belong to
multiple Drivers , but if Driver die , Car will not die , object will not be destroyed.
• We can sell car to another Driver to use it
• We can think of it as a “has-a” relationship or "whole/part" relationship.
• Driver can own many cars (Collection of cars).
Relationships between Classes

24. Composition
• Composition is a specialized form of Aggregation
• we can call this as a “death” relationship. It is a strong type of Aggregation. Child object
does not have their own lifecycle and if parent object deletes all child object will also be
deleted.
• Let’s take again an example of relationship between Car and Engine. Car HAS A Engine
but there is no independent life of a Engine and any Engine cannot belong to two different
Cars. If we delete the Car , the Engine will automatically be deleted
Relationships between Classes

26. Relationships between Classes