请教对于固定数量的 struct（例如最终 new 出来只有5种情况），如何处理更好？
💡
原文中文，约2300字，阅读约需6分钟。
📝
内容提要
作者学习 Rust 开发算卦软件，设计 Gua64 结构记录卦象信息。为提高性能，建议使用常量，简化代码，去除冗余匹配，使用标准库类型，并优化 parse_name 方法。作者对常量的使用和设计方案有疑问，寻求建议。
🎯
关键要点
-
作者开始学习 Rust，开发算卦软件，设计 Gua64 结构记录卦象信息。
-
希望通过常量提高性能，简化代码，避免冗余匹配。
-
使用标准库类型替代 gpui::SharedString，优化 parse_name 方法。
-
对常量的使用和设计方案有疑问，寻求建议。
-
建议移除 new 方法中的冗余 match，直接构造实例。
-
解耦 gpui 依赖，使用 &'static str 替代 SharedString。
-
优化 parse_name 方法，考虑返回类型改为 &'static str。
-
总结建议方案：修改 new 方法，移除 gpui 依赖。
-
作者对常量的合理性和其他方案有疑问，寻求反馈。
❓
延伸问答
如何在 Rust 中设计 Gua64 结构以记录卦象信息？
可以通过定义一个结构 Gua64，包含卦象内容、卦名、注释等信息，并使用常量来表示64个卦象。
使用常量在 Rust 中有什么性能优势？
使用常量可以避免每次调用方法进行计算，从而提高性能和简化代码结构。
如何优化 Rust 中的 parse_name 方法？
可以考虑将返回类型改为 &'static str，减少 match 的分支数量，以提高代码可读性和性能。
在 Rust 中如何处理固定数量的结构体？
可以通过直接构造实例而不是使用冗余的 match 语句来处理固定数量的结构体，简化代码。
为什么要解耦 gpui 依赖？
解耦 gpui 依赖可以使核心逻辑层独立于 UI 框架，提高代码的可维护性和灵活性。
在 Rust 中定义常量是否合理？
在已知数量的情况下定义常量是合理的，可以提高代码的清晰度和性能，但需考虑是否需要实时计算信息。
➡️
