Code Quality Improvement - Session 48: Wild arguments

When receiving shape data as strings and processing it, there are cases where a factory function commonly applied to all shapes is created using Wild arguments such as param1, param2. This problem occurs because the meaning of the arguments changes completely depending on the type of shape.

This approach causes two major problems.

• Reduced flexibility: When adding a new shape or changing the number and type of arguments, all existing function signatures must be modified, which is cumbersome.
• Reduced robustness: When the number of arguments varies, the validation code becomes complex, which increases the likelihood of leading to runtime errors.

For example, to add a new shape containing string data to a function that only accepts integer arguments, extensive modifications to existing code are required, such as changing the function's type to Any. To solve this, the responsibility of interpreting the string should not be placed in the common logic, but should instead be designed so that each Shape model directly handles it.