问题标签 [design-guidelines]

前言

谷歌风格指南包括前向声明的缺点列表

1. 前向声明可以隐藏依赖关系，允许用户代码在标头更改时跳过必要的重新编译。

2. 对库的后续更改可能会破坏前向声明。函数和模板的前向声明可以防止标头所有者对其 API 进行其他兼容的更改，例如扩大参数类型、添加具有默认值的模板参数或迁移到新的命名空间。

3. 从命名空间 std:: 前向声明符号会产生未定义的行为。

4. 可能很难确定是否需要前向声明或完整的#include。用前向声明替换 #include 可以默默地改变代码的含义：

代码：

如果#include 被替换为B 和D 的前向decls，test() 将调用f(void*)。

5. 从标头前向声明多个符号可能比简单地#includeing 标头更冗长。

6. 构造代码以启用前向声明（例如，使用指针成员而不是对象成员）会使代码变得更慢和更复杂。

问题

我对第一点特别感兴趣，因为我无法想出一个场景，即当 headers 更改时，前向 decleration 会跳过必要的重新编译。谁能告诉我这是怎么发生的？或者这是谷歌代码库固有的东西？

由于这是列表中的第一点，因此它似乎也相当重要。

在学习春天时，我偶然发现了这个问题。Java 支持已检查和未检查的异常。与语言无关的设计指南似乎偏爱未经检查的异常。这个问题就是为什么使用像 Spring 这样的控制容器的反转意味着我应该只使用未经检查的异常。

我指的是选择通过蓝牙 5 传输数据的天线的选项。在这两个 SMD 芯片天线或 PCB 轨道天线之间进行选择的任何指南。

谢谢。

我有一个只实现两个主要功能的应用程序 - 一个创建表格条目的表单和另一个使用条目屏幕作为登录屏幕查找它的表单。实现这些不同功能的屏幕流导航的最佳方式是什么？可能的选项：

1. 登录屏幕后有一个新屏幕来显示菜单以导航到表单或搜索屏幕 - 只是一个用于导航目的的屏幕不是很直观
2. 使用标签栏控制器 - 但通常标签栏至少有 3 个项目，在我的情况下只有两个
3. 还有其他建议吗？

我们正在构建一个 API，用于在数据库中插入和更新记录。因此，如果记录基于 Key 存在，则记录将被更新，如果不存在，则将其插入。

我有两个问题。

• 根据 REST 指南，设计此类 API（例如 PUT/POST 或 PATCH）的选项有哪些？对象列表应该如何表示？注意：我从我读到的其他答案中知道，对于按照 REST 指南应该如何处理存在混淆。所以，如果我能得到一些关于一般最佳实践的指导（不管 REST 部分），我就可以了
• 其次，我真正困惑的部分是如何表示这个的输出或者这个 API 应该返回什么。

对于上述主题的具体指导/意见将不胜感激。

如屏幕截图所示，为 iOS 创建每行两列的网格视图的最佳方法是什么？

我目前正在使用带有静态单元格的 tableview，但 UI 在某些 iPad 上会失真。另外如何最好地安排网格边界？目前我使用中心的图像视图，以及带有图像视图的水平单元格的新单元格。但这感觉不对。

我有一个如屏幕截图所示的 UI。我目前已经使用 tableviews 完成了这项工作。屏幕是一个带有 4 行静态原型单元格的表格视图。一个用于包含个人资料图像的标题，下一个用于个人资料简介，第三行用于收藏夹、订阅、事件图像按钮，最后一行用于内容，这是另一个表格视图。

最喜欢的部分

订阅部分

我对内容使用了一个内部表格视图，其中包含收藏夹、订阅和事件中的所有元素在一个单元格中。一次加载，我隐藏其他元素并根据图标点击仅显示一个。

问题是收藏夹部分的单元格高度不一致。标签中多于一行时存在间隙。在订阅部分，最后一项触及标签栏。

我禁用了外部表格视图的滚动，因此只有内部表格视图（内容部分）滚动，这在较小的屏幕上并不令人愉快。

内容节表视图代码为：

如何修复细胞之间的间隙？我将标签线设置为0. 如何为这样的屏幕布局 UI 元素？上述方法正确吗？或者我应该使用 UIViewController 和部分的容器视图？

有关此如何更改 iOS 中内部表格视图单元格的单元格高度的相关问题？

我有一个在本机 iOS (Swift) 中实现的应用程序。该应用程序也有一个网络版本。客户想要将我的应用程序嵌入到自己的应用程序中，并建议我使用 iFrame 并加载 Web 版本。我知道这是一个棘手的解决方案，因为 Apple 可能会因为不使用本机实现而拒绝该应用程序。

我想问的是是否有办法将我的应用程序完全打包为框架并以这种方式加载（应用程序大小相当大，具有多个视图控制器和功能）。

我了解我将无法访问 AppDelegate 等应用程序加载功能。

如果我的应用程序具有库依赖项，还会发生什么？（如 Alamofire）

还有什么我应该关心的吗？

谢谢

在这篇文章中，我使用了@Eric Lippert 的异常分类，你可以在这里找到： Vexing exceptions

在这种情况下最重要的：

愚蠢的异常是您自己的错误，您可以阻止它们，因此它们是您代码中的错误。你不应该抓住它们；这样做会隐藏代码中的错误。相反，您应该编写代码，使异常不可能首先发生，因此不需要被捕获。

外生异常看起来有点像令人烦恼的异常，只是它们不是不幸的设计选择的结果。相反，它们是杂乱的外部现实影响你美丽、清晰的程序逻辑的结果。始终处理表示意外外部条件的异常；一般来说，预测每一个可能的失败是不值得或不切实际的。只需尝试操作并准备处理异常。

就像每个开发人员可能都经历过的那样，在大型企业软件中不可能 100% 避免愚蠢的异常。

在抛出愚蠢异常的不幸情况下，我想通知用户，以便他将错误报告给我们（第三级支持）。另外，在这种情况下，我想记录一条日志级别为“错误”的消息。

对于外生异常，我想向用户显示带有一些提示的更具体的消息，因为他可能自己解决问题（也许在第一级或第二级支持的帮助下）

我目前实现这一点的方法是在低级组件中显式捕获外生异常并将它们包装到自定义异常中。然后在顶层（在我的情况下是 MVVM WPF 应用程序的 ViewModel）中，我显式地捕获自定义异常，以显示警告。在第二个 catch 块中，我捕获一般异常以显示错误。

这是区分企业应用程序中愚蠢的异常和外生异常的常见且​​良好的做法吗？有更好的方法吗？或者根本没有必要？

在阅读了这篇文章dotnetpro - Implementierungsausnahmen 之后，我还想知道，是否应该将所有（也是愚蠢的）异常包装到自定义异常中，以便在记录它们时提供更多上下文信息？

关于包装我发现以下帖子的所有异常：stackoverflow - 我应该捕获并包装一般异常吗？和stackoverflow - 我应该捕获所有可能的特定异常还是只捕获一般异常并将其包装在自定义异常中？ 它似乎很有争议并且取决于用例，所以我不确定我的情况。

ViewModel 中高级捕获处理程序的示例：

低级异常包装示例：

我将此问题移至softwareengineering.stackexchange.com，因为它更适合那里。

我正在观看 Vladimir Khorikov 的以下视频，该视频建议“重构远离异常” pluralsight.com - Applying Functional Principles in C# - Refactoring Away from Exceptions，而不是使用 Result 对象。您还可以在此处找到有关它的博客：enterprisecraftsmanship.com - 函数式 C#：处理失败、输入错误

总而言之，建议是更喜欢返回结果对象然后抛出异常。异常应该仅用于指示错误。这种方法的论据如下：

• 抛出异常的方法不是“诚实的”。通过查看方法的签名，您无法识别方法是否会失败。
• 异常处理增加了很多样板代码。
• 当异常用于控制流程时，它具有“goto”语义，您可以在其中跳转到特定的代码行。

另一方面，可以忽略返回值（至少在 C# 中），而异常则不能。

朝这个方向重构现有的企业应用程序是个好主意吗？还是一种不太激进的方法更好？（我相信通过使用类似方法的返回类型来确保避免Vexing 异常ValidateUserInput(string input)是有意义的）