Untitled
unknown
plain_text
2 years ago
2.9 kB
7
Indexable
The `nypdVTRulesEngine` class indeed seems to be quite large and complex. It appears to be responsible for a variety of tasks related to rule checking and violation handling. Applying some design patterns could help to make this class more manageable and maintainable.
1. **Strategy Pattern**: The class has many methods for checking different types of violations. These methods could be extracted into separate strategy classes, each implementing a common interface. This would make it easier to add new types of checks in the future.
2. **Factory Pattern**: The class is responsible for creating and managing various types of violations. These responsibilities could be moved to a separate factory class, which would be responsible for creating the appropriate violation objects.
3. **Command Pattern**: The class seems to be performing a series of operations (commands) on the `nypdCell` objects. These operations could be encapsulated into command objects, which would make it easier to add new operations, undo operations, or queue up a series of operations to be performed later.
4. **Observer Pattern**: If there are other objects in the system that need to be notified when a violation is detected, the observer pattern could be used. The `nypdVTRulesEngine` would become the subject, and other objects could register themselves as observers.
Here is a simplified example of how the Strategy Pattern could be applied to the violation checking methods:
```cpp
// Common interface for all check strategies
class IViolationCheckStrategy {
public:
virtual bool check(nypdCell *cell, std::vector<nypdViolation *> *vioVec, nypdGContext* gc) = 0;
};
// Concrete strategy for checking VT point touch vert spacing constraint
class CheckVTPtVertSpacingStrategy : public IViolationCheckStrategy {
public:
bool check(nypdCell *cell, std::vector<nypdViolation *> *vioVec, nypdGContext* gc) override {
// Implementation of checkVTPtVertSpacing method
}
};
// Concrete strategy for checking cross row VT constraint
class CheckCrossRowConstStrategy : public IViolationCheckStrategy {
public:
bool check(nypdCell *cell, std::vector<nypdViolation *> *vioVec, nypdGContext* gc) override {
// Implementation of checkCrossRowConst method
}
};
// In nypdVTRulesEngine class
class nypdVTRulesEngine {
private:
IViolationCheckStrategy* strategy;
public:
void setStrategy(IViolationCheckStrategy* newStrategy) {
strategy = newStrategy;
}
void checkViolation(nypdCell *cell, std::vector<nypdViolation *> *vioVec, nypdGContext* gc) {
strategy->check(cell, vioVec, gc);
}
};
```
In this example, each specific violation check is encapsulated in its own class that implements the `IViolationCheckStrategy` interface. The `nypdVTRulesEngine` class can then use these strategy objects to perform the checks, making it easier to add, remove, or modify checks in the future.Editor is loading...
Leave a Comment