This document provides an overview of object-oriented analysis and design (OOAD). It discusses why OOAD is needed, the benefits it provides, and key concepts like objects, inheritance, polymorphism, encapsulation, cohesion/coupling, and design patterns. OOAD involves analyzing a problem domain to identify objects and their relationships, then designing a conceptual solution where objects collaborate through defined responsibilities and interfaces. The document emphasizes designing for comprehensibility, extensibility, and maintainability by following OO principles like information expert, pure fabrication, and high cohesion/low coupling.

1. OOAD

2. Before we start…
• Emphasis is more on Design rather than
analysis
• The definitions I’ll use will be informal, non-
rigorous.
• I won’t go in depths of design patterns.
• My assumption is that you all know what is a
class, object, inheritance and interface.

3. Why is it needed
• Knowing rules of chess doesn’t make you
Vishwanathan Anand
• Similarly, knowing programming alone doesn’t
make you a good Software Engineer
• Learning “how to think in objects” is
absolutely critical

4. Benefits
• Comprehensibility (self-documenting)
• Extensibility
• Modifiability
• Maintainability
• Testability

5. Analysis & Design
• Analysis emphasises the study and research of
problem and requirements in order to gain
deeper understanding of them
• Design emphasises a “conceptual solution”
that fulfils the requirements

6. OO Analysis & Design
• OO Analysis:
• Find and describe the objects/entities (and
concepts) in a problem domain.
• OO Design:
• Define attributes and responsibilities of objects and
how they collaborate with each other

7. Perspectives
• Conceptual:
• “What do you want to do?”
• Implementation:
• “How exactly will you do?”

8. Cohesion and Coupling
• Cohesion:
• How strongly related methods (or responsibilities)
of that object are
• Coupling:
• How closely connected two objects are

9. OOP revisited
A. Objects:
1. Data with Methods Things with
Responsibilities
2. Entities: Representation of real world entities
3. Services: Model Concepts/Processes/sequence of
actions
4. Value object: For eg. Money

10. OOP revisited…
B. Inheritance and Polymorphism:
1. Special Case Family of similar objects
2. Inheritance + Polymorphism = Extensible,
loosely coupled objects
3. Bad Use of Inheritance = Bad Coupling,
Explosion of SubClasses

11. Bad use of Inheritance
Example

12. Dealing with changing requirements:
Suppose, we now want to control how
Border of Rectangle looks

13. Dealing with changing requirements:
Now we also want the ability to fill the Rectangle with a gradient.
But what if now we also need control over border as well as ability
to fill with gradient?
“Code Duplication”!! Okay, now what if we need all these
decorations on circle as well? Even more “Code Duplication”.
Okay, now what if even more shapes come up and more kinds of
decorations come up? Even more “Code Duplication”!!

14. Better use of Inheritance
Favour aggregation over bad use of inheritance

17. OOP revisited…
C. Polymorphism and (Type) Encapsulation:
1. Data Hiding Any kind of enclosing
2. Abstract Base Class:
A class that never gets instantiated
Representative/Placeholder for subclasses
3. Use ABC to encapsulate sub-classes from client,
thereby reducing coupling

18. OOP revisited…
D. Abstraction and (Implementation) Encapsulation:
1. Writing Abstract Base Class
Expressing Responsibilities minus
implementation
2. Think about object and it’s public interface
(responsibilities)
3. Encapsulate the nuts and bolts in private methods

19. OOD principles
1. Information Expert:
• Assign Responsibility to the object that has
necessary information to carry it out
2. Pure Fabrication:
• Assign Responsibility to a new Service object if
Info Expert hurts cohesion / reuse potential

20. OOD principles…
3. High Cohesion:
• Assign focussed, related responsibilities to an
object
4. Low Coupling:
• Avoid Bad coupling

21. Brief Intro to Design Patterns
• A Pattern is problem-solution pair that is
common, well known and has a name
• Patterns are always guided by Principles
• And you learn’t those principles in previous
slides
• Examples:
Strategy —> Polymorphism, Type Encapsulation
Facade —> Implementation Encapsulation

22. Further Reading
• Applying UML and Patterns - Craig Larmann
• Design Patterns Explained - Allan Shalloway
• Domain Driven Design - Eric Evans
(for backend developers)