Untitled

 avatar
unknown
plain_text
2 years ago
2.9 kB
4
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