OOD Ranking classes
In Object-Oriented Design (OOD), ranking classes based on their likelihood to change is crucial for creating a maintainable and robust application. This ranking helps in making informed decisions about dependencies and architecture. Here are some guidelines and factors to consider when ranking classes:
1. Understand the Domain and Requirements
- Domain Knowledge: Gain a deep understanding of the domain and requirements. Classes representing core business logic or domain entities are likely to be more stable than those representing application-specific or infrastructure concerns.
- Requirements Analysis: Analyze the requirements to identify parts of the system that are likely to change. For example, regulatory or business rules often change, while core domain concepts tend to be more stable.
2. Factors Influencing Likelihood of Change
- Volatility of Requirements: Classes that implement frequently changing business rules or user interface elements are more likely to change.
- External Dependencies: Classes that depend on external libraries, APIs, or services may need to adapt to changes in those dependencies.
- Technology Choices: Classes tied to specific technologies (e.g., database, frameworks) may need to change when the technology evolves or is replaced.
- Coupling and Cohesion: Highly coupled classes are more susceptible to change when their dependencies change. Strive for low coupling and high cohesion to isolate changes.
- Responsibility and Scope: Classes with a narrow, well-defined responsibility are less likely to change compared to those with broad, mixed responsibilities.
3. Ranking Methodology
- Stable vs. Unstable: Classes closer to the domain model are more stable. Infrastructure and utility classes are more unstable.
- Core vs. Peripheral: Core business logic classes are more stable. Peripheral classes (UI, external services) are more prone to change.
- Volatile vs. Invariant: Classes with volatile behavior (e.g., user preferences, feature toggles) are ranked higher for change likelihood. Invariant classes (e.g., mathematical models) are ranked lower.
4. Assigning Ranks
- Assign scores: Use a scoring system to rank classes. For example, on a scale of 1 to 5, where 1 indicates least likely to change and 5 indicates most likely to change.
- Categorize: Categorize classes based on their scores. Categories could be Core, Stable, Unstable, and Peripheral.
Example Ranking Process
Step 1: Identify Classes
List all the classes in your application.
Step 2: Analyze Factors
Evaluate each class against the factors influencing change likelihood.
Step 3: Assign Scores
Assign a score to each class based on your analysis.
Step 4: Categorize
Group classes into categories based on their scores.
Example Classes and Rankings
| Class Name | Description | Factors Influencing Change | Likelihood of Change (1-5) |
|---|---|---|---|
User | Core domain entity | Stable business concept | 1 |
UserController | Handles user-related HTTP requests | Frequently changing UI logic | 4 |
AuthService | Manages authentication | External API dependency | 3 |
DatabaseConnector | Manages database connections | Technology dependency | 4 |
Invoice | Core domain entity | Stable business concept | 1 |
PaymentProcessor | Handles payment processing | External service dependency | 5 |
NotificationService | Sends notifications | Often changing requirements | 5 |
Guidelines for Dependencies
- Depend on Stable Classes: Design dependencies such that stable classes are depended upon, not the other way around.
- Use Interfaces and Abstractions: Abstract away dependencies on unstable classes to minimize the impact of changes.
- Encapsulation and Isolation: Encapsulate and isolate volatile components to limit the scope of change.
By following these steps, you can effectively rank your classes based on their likelihood to change and make informed decisions about your application’s architecture and dependencies. This approach helps in creating a maintainable and adaptable system.