[OOP] Object - Oriented Design Process

Nguồn: Click here

1. Identify classes

Class identification is an important step in object-oriented design (OOD) and involves defining the objects and their properties in a software system. Here are some steps to identify classes in OOD:

• Determine the problem domain: Start by understanding the problem you're trying to solve, the objects involved, and their relationships.
• Identify candidate classes: Consider the nouns in the problem domain and identify the objects that can be modeled as classes.
• Determine the attributes of each class: Consider the properties and characteristics of each object and identify the data that needs to be stored in the class.
• Determine the behavior of each class: Identify the methods and operations that can be performed on the objects and implement them as functions or procedures in the class.
• Define relationships between classes: Identify the relationships between the classes, such as inheritance, aggregation, composition, and association, and represent them using UML diagrams.
• Refine the class model: Iterate over the class model and refine it as necessary based on feedback, changes in requirements, or further understanding of the problem domain.

Class identification is an iterative process and the classes may change as the problem domain is better understood and the design evolves. The goal is to identify the objects and their relationships in the problem domain and represent them in a way that supports the requirements and goals of the software system.

2. Identify responsibilities

 Identifying responsibilities in object-oriented design (OOD) is an important step in defining the behavior of objects in a software system. Here are some steps to identify responsibilities in OOD:

• Determine the problem domain: Start by understanding the problem you're trying to solve and the objects involved.
• Identify the classes: Consider the nouns in the problem domain and identify the objects that can be modeled as classes.
• Identify the responsibilities of each class: Determine the operations that can be performed on the objects and assign them to the appropriate class. Each responsibility should represent a single, well-defined task.
• Define the interactions between classes: Identify the relationships between the classes, including who initiates and who responds to each interaction.
• Refine the class model: Iterate over the class model and refine it as necessary based on feedback, changes in requirements, or further understanding of the problem domain.

The goal is to assign responsibilities to classes in a way that supports the requirements and goals of the software system. The classes should be loosely coupled and highly cohesive, with each class responsible for a well-defined set of tasks and interactions. By assigning clear responsibilities, you can help ensure that the system is maintainable, scalable, and easily adaptable to changing requirements.

Example of identifying responsibilities:

Responsibilities of the "Car" class could be:

Representing the physical characteristics of a car such as make, model, color, etc.

• Keeping track of the current speed and fuel level.
• Starting and stopping the engine.
• Accelerating and braking.
• Turning left and right.

Each of these responsibilities can be modeled as methods within the "Car" class. For example:

• "getMake()", "setMake()", "getModel()", "setModel()", etc. to represent the physical characteristics of the car.
• "getSpeed()", "setSpeed()", "getFuelLevel()", "setFuelLevel()" to keep track of the speed and fuel level.
• "startEngine()", "stopEngine()" to start and stop the engine.
• "accelerate()", "brake()" to control the speed.
• "turnLeft()", "turnRight()" to control the direction of the car.

3. Categories of classes

• Tangible Things: This category includes classes that represent physical or concrete objects, such as cars, books, or rooms.
• Agents: This category includes classes that represent entities that act on behalf of other objects or the system, such as employees, customers, or service providers.
• Events and Transactions: This category includes classes that represent events or transactions that occur within the system, such as sales, payments, or appointments.
• Users and Roles: This category includes classes that represent the users of the system and their roles, such as customer, administrator, or analyst.
• Systems: This category includes classes that represent larger systems or components within the system, such as the voice mail system, a database, or a network.
• System interfaces and devices: This category includes classes that represent the interfaces and devices used by the system, such as screens, keyboards, or printers.
• Foundational Classes: This category includes classes that provide the foundation for other classes in the system, such as basic data structures, utility classes, or error handling classes.

These categories can help guide the design and organization of classes within a system, and can also be used to identify potential relationships between classes. The categories are not strict and may overlap in some cases, but they can provide a useful framework for thinking about class design and organization.

4. Class Relationship

Class relationships describe the ways in which classes interact with each other. The following are the most common class relationships:

• Association: A relationship between two classes in which one class uses another. For example, a Car class and a Driver class can have an association, where a car can have a driver and a driver can drive a car.
• Aggregation: A special type of association where an object can contain another object but does not control its lifecycle. For example, a Department class and an Employee class can have an aggregation relationship, where a department can have employees, but employees can exist without a department.
• Composition: A special type of aggregation where an object cannot exist without another object. For example, a Car class and an Engine class can have a composition relationship, where a car must have an engine, and the engine cannot exist without a car.
• Inheritance: A relationship between a superclass and a subclass, where a subclass inherits properties and behavior from a superclass. For example, a Vehicle class can be a superclass and a Car class can be a subclass, inheriting properties and behavior from the Vehicle class.
• Interface implementation: A relationship between a class and an interface, where a class implements the methods defined in an interface. For example, a Car class can implement the Drivable interface, which defines methods for starting and stopping the engine.

These class relationships help in modeling the real-world objects and their interactions in a software system.

5. Multiplicities

Multiplicities refer to the number of objects of one class that can be related to objects of another class. In object-oriented modeling, multiplicities are used to describe the relationship between classes and are often represented using symbols such as arrows and numbers.

Here's an example to illustrate multiplicities: Imagine we have two classes: Student and Course. We can define the relationship between these classes as follows:

• One-to-one: One student can enroll in only one course, and one course can only have one student enrolled. This relationship can be represented as 1..1 on both sides of the relationship arrow.
• One-to-many: One student can enroll in multiple courses, but one course can only have one student enrolled. This relationship can be represented as 1..* on the student side and 1 on the course side of the relationship arrow.
• Many-to-many: Many students can enroll in multiple courses, and many courses can have multiple students enrolled. This relationship can be represented as *..* on both sides of the relationship arrow.

In these examples, the multiplicities describe the number of objects on either side of the relationship and help to define the constraints and limitations of the relationship between the classes.