Skip to content

Refactor FilterService God Object

Priority: 🔴 CRITICAL Status: Planning Related QA Analysis: qa-analysis-overview.md

Problem Statement

Service/Api/FilterService.php has become a god object with excessive complexity:

Violations

  • Class Complexity: 83/60 (38% over threshold)
  • Method Complexity:
    • Line 68: applyFilter() - CC: 11
    • Line 312: applyLocationHierarchyFilter() - CC: 14, NPath: 1,920

Impact

  • User Experience: Core API filtering affects all user-facing features
  • Extensibility: Adding new filter types is difficult and risky
  • Bug Risk: Complex query building logic prone to errors
  • Testability: Difficult to test all filter combinations thoroughly

Guideline Violations

  • God Objects Anti-pattern: Class has too many responsibilities
  • SOLID - Single Responsibility Principle: Handles too many filter types

Current Responsibilities

FilterService appears to handle:

  1. General filter application logic
  2. Location hierarchy filtering (complex)
  3. Multiple other filter types
  4. Query builder orchestration
  5. Filter validation
  6. Filter parameter processing

Proposed Refactoring Strategy

Step 1: Analyze Filter Types

  • Document all filter types currently supported
  • Identify filter-specific logic vs shared logic
  • Map dependencies between filters
  • Understand query building patterns

Step 2: Design Filter Strategy Pattern

Implement Strategy or Chain of Responsibility pattern:

Potential Structure:

FilterInterface
├── LocationHierarchyFilter (most complex - line 312)
├── [OtherSpecificFilters]
├── FilterChain (orchestrator)
└── QueryBuilderHelper (shared utilities)

Step 3: Extract Filter Implementations

  • Create dedicated filter classes for each filter type
  • Extract applyLocationHierarchyFilter() to dedicated service (highest complexity)
  • Move filter-specific logic out of god object
  • Keep FilterService as thin orchestrator

Step 4: Simplify Filter Application

  • Reduce applyFilter() complexity (line 68)
  • Use polymorphism instead of conditionals
  • Implement clear filter pipeline
  • Standardize filter interfaces

Step 5: Testing Strategy

  • Unit test each filter independently
  • Integration test filter combinations
  • Performance test complex filter queries
  • Verify API response correctness

Success Criteria

  • FilterService class complexity < 60
  • All methods have cyclomatic complexity < 10
  • Each filter type has dedicated, testable class
  • Easy to add new filter types
  • No regression in API functionality
  • Improved query performance (if possible)

Risk Assessment

High Risk:

  • User-facing API functionality
  • Complex SQL query building logic
  • Many filter combinations to test

Mitigation:

  • Comprehensive integration tests before refactoring
  • Test all documented filter combinations
  • API contract tests to prevent breaking changes
  • Staged rollout with feature flag if possible

Estimated Effort

Medium-High - Significant refactoring:

  • Multiple filter types to extract
  • Complex query building logic
  • Extensive testing required
  • API stability critical

Dependencies

None - can be addressed independently

  • applyLocationHierarchyFilter() (line 312) is most complex - extract first
  • applyFilter() (line 68) complexity will reduce after extracting strategies

Notes

  • Second most critical god object (83/60 complexity)
  • Directly impacts user experience
  • Consider extracting most complex filter first (LocationHierarchy)
  • May reveal opportunities for query optimization
  • Could improve API performance as side benefit