Technical Summary: Benefits of Applying Software Design Patterns to Backend Rust Applications

Problem Statement

While the Rust programming language offers compile-time safety guarantees, memory safety without garbage collection, and a distinct type system, there is a lack of empirical research regarding the effectiveness of software design patterns within this context. Most existing design patterns originate from Object-Oriented Programming (OOP) paradigms (e.g., the Gang of Four patterns), which may not translate directly to Rust's multi-paradigm nature. Furthermore, previous studies on design patterns have yielded controversial results regarding their impact on code quality, often lacking context-specific data. This thesis addresses the gap in understanding how specific design patterns affect software quality and the enforcement of invariants in production-grade Rust backend applications.

Methodology

The study employs a mixed-method approach combining quantitative metrics and qualitative expert analysis to evaluate the impact of design patterns on three representative use cases from production backend applications at Otto GmbH & Co. KGaA.

Case Studies

Three distinct use cases were selected to represent common architectural patterns in Rust backends:

1. Use Case 1 (FT9 Detailview Service): A service with a long, linear sequence of operations involving multiple dependencies and conditional logic.
2. Use Case 2 (FT9 Tag Component Handler): A handler dealing with input validation of domain-specific expressions ("Dreson") using raw strings.
3. Use Case 3 (Boxfish Lambda Handler): A serverless function involving shared mutable state, deep function hierarchies, and implicit error handling.

Refactoring Strategy

Two specific design patterns were applied to address identified code smells:

• Typestate Pattern: Applied to Use Cases 1 and 3. This pattern encodes the state of an object in its type, ensuring that operations are only performed in valid states. It leverages Rust's ownership and type system to enforce execution order and prevent invalid states at compile time.
• Newtype Pattern: Applied to Use Case 2. This pattern wraps primitive types (e.g., String) in a new struct to enforce domain-specific invariants (e.g., validation) immediately upon construction, adhering to the "Parse, don't validate" principle.

Evaluation Framework

The refactored code was assessed against criteria derived from the ISO/IEC 25010 SQuaRE quality model:

• Quantitative Metrics:
  • Time Behaviour: Measured via micro-benchmarking using criterion-rs to detect performance regressions.
  • Static Code Analysis: Metrics included Cyclomatic Complexity (CyC), Cognitive Complexity (CoC), Halstead's Difficulty (HDiff), and Maintainability Index (MI).
• Qualitative Analysis: Semi-structured interviews were conducted with four senior Rust developers (6+ years experience, 2+ years in Rust) to evaluate Modularity, Reusability, Analysability, Modifiability, Testability, and Faultlessness.

Key Results

1. Performance Impact

Across all three use cases, the application of design patterns resulted in no statistically significant degradation in runtime performance.

• Use Case 1: Showed a slight improvement (1.86%) within the noise threshold.
• Use Case 2: Showed a negligible increase (1.25%) within the noise threshold.
• Use Case 3: Showed a non-significant change due to high variance in the test environment, but no evidence of performance loss.
  The structural overhead introduced by the patterns (e.g., additional structs) proved to be a zero-cost abstraction in practice.

2. Quality Attribute Improvements

• Faultlessness: Both patterns significantly improved faultlessness. The Typestate pattern enforced execution order and prevented invalid states (e.g., reading a closed file) at compile time. The Newtype pattern ensured that invalid data could not propagate through the system, shifting error detection from runtime to compile time.
• Testability: The Typestate pattern significantly enhanced testability by isolating logic into smaller state transitions, reducing the need for complex mocking of dependencies. The Newtype pattern allowed validation logic to be tested in isolation.
• Analysability: The Typestate pattern reduced the Cognitive Complexity of large functions by distributing logic across smaller units. However, experts noted that the increased volume of boilerplate code (structs and function signatures) could initially hinder readability for developers unfamiliar with the pattern.
• Modifiability: Changes became safer due to compile-time guarantees. However, modifying the structure of a state machine required updating multiple dependent states, which some experts viewed as increased effort, though others saw it as a positive enforcement of correctness.
• Modularity & Reusability: Results were mixed. While the Newtype pattern improved modularity by decoupling validation logic, the Typestate pattern created tightly coupled states that were difficult to reuse across different contexts without significant refactoring.

3. Expert Consensus

Experts agreed that the patterns offered high value for specific scenarios:

• Newtype: Highly recommended for primitive data types requiring validation, offering high returns with low cost.
• Typestate: Most beneficial for code with extensive branching logic and high numbers of invariants. Experts noted that for linear flows, the boilerplate overhead might outweigh the benefits.

Significance and Contributions

This work provides the first empirical assessment of software design patterns specifically within the context of Rust backend applications. Its primary contributions include:

1. Empirical Evidence: It moves beyond theoretical discussions to provide data-driven evidence on how Typestate and Newtype patterns affect code quality metrics and runtime performance in real-world systems.
2. Methodological Framework: The study establishes a reusable evaluation framework combining benchmarking, static analysis, and expert interviews, tailored to the unique constraints of Rust (e.g., acknowledging the limitations of static metrics in capturing cognitive load).
3. Contextual Recommendations: The paper formulates specific guidelines for when to apply these patterns:
   • Use Newtype for enforcing invariants on primitive types ("Parse, don't validate").
   • Use Typestate for complex state machines with branching logic, rather than simple linear flows, to justify the structural overhead.
   • Adopt the Functional Core - Imperative Shell (FC-IS) principle in conjunction with Typestate to maximize testability and purity.

The thesis concludes that while design patterns in Rust do not universally improve all quality attributes, they are powerful tools for leveraging the language's type system to enforce correctness and improve maintainability, provided they are applied with an understanding of their trade-offs regarding boilerplate and coupling.