面试题：TypeScript接口只读与可选属性在复杂数据结构设计中的权衡

Question

假设你正在设计一个前端应用的数据模型，其中有一个`User`接口，用户的`email`是唯一标识且不应被修改（只读属性），`phoneNumber`可能存在也可能不存在（可选属性）。此外，`User`对象还需要嵌套另一个接口`Address`，`Address`中的`street`是只读的，`apartmentNumber`是可选的。请详细阐述如何合理设计这些接口以及它们之间的关系，包括考虑到数据的一致性、可维护性和扩展性，同时分析在不同操作场景下只读属性和可选属性可能带来的影响及应对策略。

Answer 1

设计接口

1. Address接口

interface Address {
  readonly street: string;
  apartmentNumber?: string;
}

在这个接口中，street被定义为只读属性，这意味着一旦Address对象创建，street的值就不能被修改，确保了地址中街道信息的稳定性。apartmentNumber被定义为可选属性，因为不是每个地址都有公寓号码，这种设计提高了接口的灵活性。

2. User接口

interface User {
  readonly email: string;
  phoneNumber?: string;
  address: Address;
}

User接口中，email作为唯一标识被定义为只读属性，防止在后续操作中意外修改导致数据不一致。phoneNumber是可选属性，因为有些用户可能没有提供电话号码。address属性嵌套了Address接口，建立了用户与地址之间的关系。

数据一致性、可维护性和扩展性考虑

1. 数据一致性
   • 通过将email和street设置为只读属性，保证了这些关键标识信息不会被误修改，维持了数据的一致性。例如，在用户登录、数据查询等操作中，始终以只读的email作为唯一标识，不会出现因为email修改而导致的数据混乱。
   • 对于可选属性phoneNumber和apartmentNumber，在处理相关逻辑时，需要明确检查它们是否存在，以避免空指针错误等问题，确保数据在不同操作中的一致性。
2. 可维护性
   • 接口的定义清晰明确，属性的含义和必要性一目了然。例如，看到User接口就知道email是唯一标识且不可变，phoneNumber可能不存在，address包含地址信息，方便开发人员理解和维护代码。
   • 当需要修改或扩展功能时，只读属性和可选属性的设计使得代码的修改范围相对可控。比如，如果要添加新的用户地址信息，只需要在Address接口中进行扩展，而不会影响到User接口中其他关键属性的逻辑。
3. 扩展性
   • 对于未来可能的需求变化，这种设计具有良好的扩展性。例如，如果需要为用户添加更多的联系方式，只需要在User接口中添加新的可选属性即可。如果要对地址信息进行更细致的划分，也可以在Address接口内部进行扩展，而不会破坏现有代码的整体结构。

不同操作场景下的影响及应对策略

1. 只读属性
   • 创建场景：在创建User或Address对象时，必须提供只读属性的值。例如创建User对象时，必须传入唯一的email值，创建Address对象时必须传入street值。这确保了对象在创建时关键信息的完整性。
   • 更新场景：尝试修改只读属性会导致错误，如在TypeScript中会提示编译错误。如果确实需要修改email或street，需要特殊的逻辑处理，例如通过创建新的对象并删除旧对象来模拟“修改”操作，同时要确保相关的关联数据也进行相应的更新，以维护数据一致性。
2. 可选属性
   • 读取场景：在读取phoneNumber或apartmentNumber时，需要进行存在性检查，以避免空指针错误。例如在JavaScript中，可以使用if (user.phoneNumber)来判断电话号码是否存在，然后再进行相应操作。
   • 更新场景：更新可选属性相对灵活，因为它们可能原本就不存在。在更新时，直接设置新值即可，但同样需要注意检查属性是否存在，尤其是在删除操作时，如果要删除phoneNumber，需要先检查其存在性，避免无效操作。