`fixed_design` split into smaller export function

[elong0527]

Each method in fixed_design() should be its own function

1. For better documentation. each method may require specific arguments in the ...
2. Reduce maintenance efforts. The function body contain > 600 lines

We probably should have functions corresponding to each method, e.g.:

• fixed_design_ahr()
• fixed_design_wlr()
• fixed_design_maxcombo()
• fixed_design_rmst()
• fixed_design_milestone()

[nanxstats]

This would be a much welcomed change. Functions should have cyclomatic complexity of less than 15. fixed_design() has 73. I had to disable this complexity check in .lintr so it can pass.

[LittleBeannie]

I agree! Can we have fixed_design to call fixed_design_ahr, fixed_design_wlr, ...?

[nanxstats]

I agree! Can we have fixed_design to call fixed_design_ahr, fixed_design_wlr, ...?

Let's discuss how we can balance these considerations. Some initial thoughts below as a start...

Reasons to still include a fixed_design() function:

1. Abstraction and simplicity: If users typically use all or most methods at once, a fixed_design() function provides a simpler interface.
2. Backward compatibility: If fixed_design() is widely used in existing code, maintaining it can ease the transition and prevent breaking changes.

Reasons to not include a fixed_design() function per SOLID principles:

1. Single Responsibility Principle: Our current fixed_design() does more than it should. By breaking it into smaller functions, each function has one clear responsibility, improving readability and maintainability.
2. Open-Closed Principle: If we add more methods in the future, we will need to modify fixed_design(), violating OCP (software entities should be open for extension, but closed for modification). Using smaller functions makes extension easier and less error-prone.
3. Liskov Substitution Principle: A fixed_design() introduces variability that can lead to inconsistency and unexpected behavior, violating LSP. Smaller functions provide predictability and consistency.
4. Interface Segregation Principle: A larger fixed_design() might force unnecessary dependencies. Smaller functions allow users to depend only on what they need.
5. Dependency Inversion Principle: A large fixed_design() may become tightly coupled with smaller functions' implementation details, violating DIP. Separating them would promote better encapsulation and abstraction.

[LittleBeannie]

Decision: delete fixed_design and divide them into

fixed_design_ahr()
fixed_design_wlr()
fixed_design_maxcombo()
fixed_design_rmst()
fixed_design_milestone()