问题标签 [conceptual]

当我在 Xcode 中创建一个UIViewController时，我可以决定添加一个 nib 文件。假设我此时不添加 nib 文件。我可以稍后简单地添加一个 nib 文件并将其命名为与 ViewController 相同的名称吗？

我问这个是因为我目前有一个具有某种背景颜色的表格视图。但是，当显示视图时，它看起来像是UITableView使用了泛型。

所以就像我的 nib 文件被忽略了，实际上，当我删除 nib 文件时，它仍然可以正常工作，但没有背景颜色。

对于大学项目，我正在推出一些云文档编辑器。其中一项功能是为多个用户提供实时编辑它的可能性。问题是如何解决这个问题？

我知道谷歌文档，正在幕后进行一些高级 DOM 操作，但如果我只有简单的纯文本区域，那么同步更改的最佳方式是什么，请在幕后合并它们并在用户前端进行更新。我会使用 rails、mongoid 和 js/jquery。

任何想法如何实施？

我正在开发一个 android 应用程序，但在弄清楚某些代码应该放在哪里时遇到了问题。

该应用程序基于一些 Commonsware 的东西，以及记事本教程。它有项目，每个项目都可以打开、编辑或“运行”。

现在，有一个 dbadapter 类，它具有“项目”的基本 CRUD 操作。将 open、edit 或 run 方法放在那里似乎没有意义，因为这些方法涉及启动活动，而我无法从 dbadapter 内部执行此操作。

我目前在项目的详细视图中有代码。我希望能够从详细视图之外的其他活动中的上下文菜单中调用这些相同的方法。

代码应该放在哪里？我应该有一个项目类吗？那将如何与 dbadapter 和游标接口？我是否应该制作某种看不见的碎片——可能不会，但我有点抓住稻草了？

来自同一开发人员的 AppA 和 AppB 是否有可能在给定设备上共享一些本地资源。例如，他们可能对某些服务使用相同的登录凭据。

这个问题是概念性的，围绕 OOP 中的 MVC 模式。情节如下：我们在一个富客户端应用程序中，它与 REST Web 服务一起工作。我们向服务器上的资源发出 GET 请求，服务器返回 XML 格式的响应。响应看起来像一个 RSS 提要。客户端应用程序需要将此 XML 解析并显示为可读的 mod。

我制作了一个模型对象，它基本上反映了一个服务器数据库表，我还有一个解析器和一个视图控制器（显然还有一个视图）。

这是它今天的工作原理。视图控制器告诉解析器开始解析，解析器（SAX 类型）读取 XML，并实例化模型对象并在其属性中加载详细信息。每次解析器完成一个项目时，它都会通过委托方法通知视图控制器。它将解析的项目（类型是模型对象）发送到视图控制器。视图控制器将此项目添加到集合中。

当解析器完成对 XML 的解析时，它会通知视图控制器，然后视图控制器读取集合中的每个项目并构建视图。

这是我的问题。

1. 这是一个很好的实现吗？
2. 我认为集合所有者应该直接是模型，所以视图控制器要求模型开始解析，解析器通知模型而不是视图控制器，最后模型将集合发送回视图控制器。这是否更好 ？
3. 我应该合并模型和解析器吗？

这是一个概念性问题，我无法在 SO 中找到答案，所以我开始了：

为什么要使用实例变量来连接控制器和视图？难道我们没有两个不同类的两个不同对象（控制器与视图）。那么，当视图被渲染时，我们处于不同的上下文中，但我们使用的是另一个对象的实例变量？这不是以某种方式破坏封装吗？

Rails 如何做到从一个对象到另一个对象的匹配？它是否将控制器的所有实例变量克隆到视图中？

我可能遗漏了一些东西，但是做这件事有什么区别：

Stephen Toub 在博客中写道

SynchronizationContext 和 TaskScheduler 都是代表“调度器”的抽象，它是你给它一些工作的东西，它决定了何时何地运行该工作。有许多不同形式的调度程序。例如，ThreadPool 是一个调度程序：您调用 ThreadPool.QueueUserWorkItem 来提供一个要运行的委托，该委托排队，并且 ThreadPool 的一个线程最终选择并运行该委托。您的用户界面还有一个调度程序：消息泵。

因此System.Reactive.Concurrency.EventLoopScheduler，响应式扩展的Dispatcher、ThreadPool、TaskScheduler、SyncrhonizationContext和IScheduler 实现在这个意义上都是“调度程序”。

它们之间有什么区别？

为什么它们都是必要的？我想我得到了 EventLoop、Dispatcher、ThreadPool。IScheduler 也有很好的解释。
但是我仍然不清楚 TaskScheduler 和 SyncrhonizationContext 。

Stephen Cleary 的优秀文章解释了 SyncrhonizationContext，我想我明白了。那么为什么我们需要TaskScheduler，目前还不清楚。

请解释或指出来源。

由于我对这个问题（关于此类系统的实施）的系统设计有一些负面评价，我希望如果我提出问题，我可以得到一些更好的建议。

我正在尝试设计一个模块化应用程序，用于视频帧中的特征匹配（例如，匹配电影或视频的非常接近的帧，如Sivic，Zisserman的这篇文章中的“产品”）。

这个想法是允许在不同的特征检测算法以及不同的匹配过程之间轻松切换。另外，根据我的研究，我的理解是只有几个基本的匹配过程，而新的匹配方法主要侧重于对不良匹配的额外剪枝过程（例如同一篇文章中的空间一致性）。所有剪枝过程都需要完成初始匹配，然后对从匹配耦合的基础图像和查询图像中提取的特征做一些额外的工作，拒绝错误的匹配。

我对设计的想法如下：

• 实现一个基本接口featureDetector
• 所有具体的特征检测算法都继承自featureDetector接口（例如siftDetector）
• 实现一个基本接口featureMatcher
• 所有具体的匹配方法都从featureMatcher接口继承（例如class bruteForceMatcher，或 OpenCV 匹配器的包装器，如cvMatcher）
• imageMatcher实现一个实现策略模式的基本接口，以允许选择featureDetector和featureMatcher
• 对于所有匹配的修剪过程，实现一个继承基本匹配接口的装饰器接口：class matcherDecorator : public imageMatcher
• 每个额外的修剪/过滤过程都实现了matcherDecorator接口（例如spatialConsistencyFilter）并且只包含imageMatcher*作为（唯一）参数的构造函数（表示要装饰的组件）

在这个问题中向我指出的问题来自于特征检测和匹配过程的具体结果，它们涉及设计的装饰器部分。每个都imageMatcher应该包含从两个图像（基本和查询）中提取的特征，以及提取的特征之间的匹配。特征的内部表示与通过以下公共访问功能提供给用户的特征描述符略有不同imageMatcher：

现在，由于特征向量（以及匹配向量）非常“重”，我不想在使用它们时将它们复制到每个嵌套的装饰器（过滤器）中。我对向量没有任何问题matches，因为它为用户提供了一个公共接口，允许装饰器访问引用并省略复制数据的需要。feats另一方面，向量不提供这样的接口，它们的访问功能要求我不仅要进行复制，还要重新计算特征的内部表示。这反过来导致装饰器需要访问内部超类指针的私有（或受保护）变量。

我设法在不违反任何隐私限制的情况下授予我对所需向量的自我访问权限（我（认为）我没有做任何邪恶的实施），但有人建议访问超类的私有成员的想法违反了装饰器模式的想法。

综上所述，我对有关如何重构代码、对当前实现的评论以及与我的应用程序设计有关的任何其他建议感兴趣。

我们的一位培训师在解释 CountDownLatch 和 CyclicBarrier 之间的区别时给出了一个示例。

CountDownLatch：假设一块石头可以由 10 个人举起，那么您将等待所有 10 个人来。然后只有你可以举起石头。

CyclicBarrier: 如果你要去野餐，你需要先在某个共同点见面，从那里开始你的旅程。

如果有人同意这些意见，请给我一些细节。

我已经阅读了这两个类的 sun API。但我需要更多解释。