Object-Oriented Design in Software Engineering: Principles, Process & Examples
For example, a library system naturally contains objects such as a Book, Member, Librarian, and Loan. Each object contains its own data and performs particular operations. Object-Oriented Design helps us decide how these objects should be organised and how they should communicate with one another.
What is Object-Oriented Design?
Object-Oriented Design is the process of converting software requirements into a design made of classes, objects, attributes, methods, interfaces, and relationships.
Instead of asking only:
Object-Oriented Design asks:
This change in thinking is the most important part of Object-Oriented Design.
Understanding Class and Object
Students often use the words class and object together, but they are not exactly the same.
Simple Example
Suppose we create a class called Student.
name
course
semester
viewResult()
payFee()
The class describes what every student object can contain and what operations it can perform.
For example:
Object 1
Name: Vishal
Course: MCA
Semester: 3
Object 2
Name: Rahul
Course: BCA
Semester: 5
Object = Actual Thing Created from Blueprint
State, Behaviour and Identity of an Object
An object is normally understood through three important characteristics.
State
State represents the current data stored inside an object.
Example: account balance, student name, or book availability.
Behaviour
Behaviour represents what operations the object can perform.
Example: withdrawMoney(), issueBook(), calculateResult().
Identity
Identity makes one object distinguishable from another object even when they belong to the same class.
Principles of Object-Oriented Design
Object-Oriented Design uses several important principles to create software that is easier to understand, modify, test, and maintain.
1. Abstraction
Abstraction means showing the important features of an object while hiding unnecessary implementation details.
When we use an ATM, we see operations such as Withdraw, Deposit, and Check Balance. We do not need to understand the internal banking code to use those operations.
2. Encapsulation
Encapsulation means keeping related data and the operations that work on that data together inside a class.
It also helps protect internal data from uncontrolled access.
3. Inheritance
Inheritance allows a new class to acquire properties or behaviour from an existing class.
For example:
Person → StudentPerson → Teacher
Student and Teacher can reuse common properties such as name, age, and address from the Person class.
4. Polymorphism
Polymorphism allows the same interface or operation to behave differently depending on the object that performs it.
For example, a method named calculateSalary() may work differently for a permanent employee and a contract employee.
5. Modularity
Modularity means organising the software into separate classes or components having clear responsibilities.
If one class performs too many unrelated tasks, the design becomes difficult to maintain.
6. Information Hiding
A class should expose only the information required by other parts of the system. Internal implementation details should remain hidden whenever possible.
7. High Cohesion and Low Coupling
A well-designed class should contain closely related responsibilities. At the same time, classes should avoid unnecessary dependency on one another.
High Cohesion
A class performs a focused set of related responsibilities.
Low Coupling
Classes depend on each other only as much as necessary.
Relationships Between Classes
Classes rarely work completely alone. Object-Oriented Design therefore defines relationships between different classes.
Example: Teacher teaches Student.
Example: Department has Teachers. A teacher may continue to exist even if a particular department is reorganised.
Example: an Order may contain OrderItems that belong to that order.
Example: Student is a Person.
Example: a ReportGenerator may use a Printer service.
Object-Oriented Design Process
There is no value in randomly creating classes. A good design follows a logical process.
Role of UML in Object-Oriented Design
UML stands for Unified Modeling Language. It provides standard visual ways to represent the structure and behaviour of software systems.
Different UML diagrams can answer different design questions.
Class Diagram
Shows classes, attributes, operations, and relationships.
Object Diagram
Shows particular object instances and their relationships at a specific point in time.
Sequence Diagram
Shows how objects communicate with one another in a time-ordered interaction.
State Diagram
Shows how the state of an object changes after different events.
Activity Diagram
Represents workflow and the sequence of activities in a process.
Use Case Diagram
Helps represent users and the major services they expect from the system.
Complete Example: Library Management System
Suppose we have to design a simple college library system where students can search books and issue available books.
Step 1: Identify Important Objects
From the requirements, possible domain objects include:
- Book
- Member
- Loan
- Librarian
- Library
Step 2: Convert Important Concepts into Classes
Step 3: Define Relationships
A Member may borrow a Book. When the issue is successful, a Loan object records the transaction.
The Librarian manages issue and return operations.
Step 4: Define Object Interaction
This is the main strength of Object-Oriented Design. Each class has a clear responsibility instead of placing every operation inside one large program.
How Objects Communicate
Objects complete useful work by sending requests or calling operations provided by other objects.
Consider an online shopping system.
Instead of one function controlling everything, different objects cooperate to complete the transaction.
Responsibility-Based Design
A very useful question during OOD is:
For example, the Book class should know its title, author, ID, and availability. It should not normally be responsible for unrelated tasks such as calculating a student's examination marks.
Keeping responsibilities focused improves cohesion and makes the design easier to understand.
SOLID Principles in Object-Oriented Design
SOLID is a popular group of object-oriented design guidelines. You do not need to memorise complicated definitions first. Understand the purpose of each principle.
S Single Responsibility
A class should have a clear and focused responsibility instead of handling many unrelated jobs.
O Open/Closed
A design should allow useful extension without forcing unnecessary modification of stable existing code.
L Liskov Substitution
A suitable subtype should be usable where its parent type is expected without breaking the expected behaviour.
I Interface Segregation
Classes should not be forced to depend on operations they do not need.
D Dependency Inversion
High-level design should avoid unnecessary dependence on specific low-level implementations and should prefer suitable abstractions.
Example: Poor Design vs Better Object-Oriented Design
Poor Design
One StudentManagement class:
- Stores student data
- Calculates fees
- Sends emails
- Generates results
- Prints reports
- Handles login
The class has too many unrelated responsibilities.
Better Design
Responsibilities may be divided into:
- Student
- FeeService
- ResultService
- NotificationService
- AuthenticationService
Each part has a clearer purpose.
Function-Oriented Design vs Object-Oriented Design
| Basis | Function-Oriented Design | Object-Oriented Design |
|---|---|---|
| Main Focus | Functions and processes | Objects and their responsibilities |
| Main Unit | Function or module | Class and object |
| Data | Often processed by separate functions | Data and related behaviour are grouped together |
| Design Approach | Usually functional decomposition | Identify objects, responsibilities, relationships, and interactions |
| Common Models | DFD and Structure Chart | UML diagrams such as Class and Sequence diagrams |
| Reusability | Possible through functions and modules | Supported through classes, composition, inheritance, interfaces, and reusable components |
| Real-World Mapping | Focuses more directly on processing | Often maps naturally to domain entities |
| Change Management | Shared data changes can affect several functions | Good encapsulation can help localise many changes |
Advantages of Object-Oriented Design
Better Modularity
Software is divided into focused classes and objects.
Improved Maintainability
Well-designed classes can make changes easier to locate and manage.
Reusability
Existing classes, interfaces, composition, and inheritance can support reuse.
Natural Problem Modelling
Many real-world domains can be represented through meaningful objects.
Better Information Hiding
Internal details can be protected behind clear class interfaces.
Easier Team Development
Different developers can work on well-defined classes or components.
Limitations of Object-Oriented Design
Initial Design Effort
Good classes and relationships require careful analysis before coding.
Can Be Over-Designed
Creating unnecessary classes, inheritance levels, or design patterns can make a simple system more complicated.
Requires Proper Modelling
Poor class identification can produce confused responsibilities and unnecessary dependencies.
Not Every Problem Needs Complex OOD
Very small procedural tasks may not need a large object-oriented model.
Common Mistakes Students Make
Memory Trick for Object-Oriented Design Process
U – Use Cases
C – Classes
R – Responsibilities & Relationships
I – Interactions
R – Refinement
Important Exam Questions
Important Long Answer Question
Quick Revision Notes
Objects and responsibilities
Class
Object
State and behaviour
Abstraction, Encapsulation, Inheritance, Polymorphism
Class Diagram
Sequence Diagram
High Cohesion + Low Coupling
Association, Aggregation, Composition, Inheritance
Requirements → Objects → Relationships → Interaction → Refinement
Frequently Asked Questions
What is the main purpose of Object-Oriented Design?
The main purpose is to organise software around interacting objects with clear data, behaviour, responsibilities, and relationships.
What is the difference between a class and an object?
A class is a blueprint or definition, while an object is an actual instance created from that class.
Which UML diagram is most important for Object-Oriented Design?
Class diagrams are particularly important for representing static class structure, while sequence diagrams are useful for understanding interactions between objects.
Why is encapsulation important?
Encapsulation helps organise related data and behaviour together and reduces unnecessary access to internal details.
What makes a good object-oriented design?
A good design normally has clear responsibilities, meaningful classes, simple interfaces, high cohesion, controlled coupling, useful abstractions, and relationships that correctly represent the problem domain.
Conclusion
Object-Oriented Design becomes much easier when you stop trying to memorise all the technical terms separately.
Start with the real-world problem. Identify the important entities, convert suitable entities into classes, decide what each class should know and do, and then define how those objects communicate.
Principles such as abstraction, encapsulation, inheritance, polymorphism, modularity, high cohesion, and low coupling help improve the quality of the design. UML diagrams then provide a visual way to communicate that design clearly.
For exams, remember this simple flow:
If this flow is clear, Object-Oriented Design will no longer feel like a group of separate definitions. You will understand it as one complete method for building well-structured software systems.
