如何组织我的代码以选择性地为我的逻辑层提供支持视图？

Question

我有点怀疑它是否属于stackoverflow，请告诉我是否应该发布到codereview或programmers。

我想为iOS编写一个可重用的组件，它可以执行以下操作：

1. 接受一个数字作为输入，我们称之为inputNumber
2. 录制音频10秒或直到用户停止录制
3. 录制期间显示实时测光
4. 录制完成后，使用提供的inputNumber检查录制内容（目前我们并不关心此部分）
5. 允许用户播放录制的音频
6. 返回录制文件的路径
7. 根据第4步检查
返回YES或NO

GUI非常简单，只有两个按钮（播放/暂停和录制/停止）以及用于在录制期间显示音频计量的视图。 像这样：



现在，我已经在单例“管理器”类中实现了我需要的所有逻辑，我想要做的还是提供GUI。这意味着消费者不会关心启用/禁用按钮，显示/隐藏仪表等。

我希望其他人能够继续使用这个“经理”（并且可能会重构以停止成为单身人士），但同时我想提供将其用作“放入“视图。

所以，这是一个如何设置整个架构的问题。

现在我的经理只有一种方法：

typedef void(^CompletionBlock)(BOOL isValid, NSString* filePath, NSError *error);

-(void)evaluateRecordingForInputNumber:(NSNumber *)inputNumber completion:(CompletionBlock)completionBlock;

这就像我想要的那样。

但是如果我介绍一个视图，我的API应该如何？编写一个自定义的UIView -init似乎不正确，它将扮演上述方法的角色，因为理想情况下我想将此视图重用于不同的模型类（提供inputNumber）需要评估。

如何在我的案例中选择子类NSObject，UIControl或UIView？有没有一种很好的方法可以将我的“引擎”用作独立组件，还可以选择提供支持视图层？

Answer 1

我认为这种耦合在很大程度上取决于您如何设想使用的自定义视图/管理器。

人们可以在没有视图的情况下使用很多逻辑，视图只是一个可选功能吗？如果是这样，可能有必要继承NSObject并将视图证明为管理器本身的属性。通过这种方式，人们可以将您的经理类作为独立使用，而在需要它的UIView中，他们可以执行以下操作：

[self.view addSubview:myCustomManager.audioView];

另一方面，如果没有UIView本身的经理类对你的用户没有价值，那么我认为继承UIView很有意义，并隐藏你的经理类在UIView后面。使用这种实现方式的窗口小部件的一个示例是stripe：Stripe iOS Widget。一切都基于他们的'STPView'，就像检索充电令牌一样：

[self.stripeView createToken:^(STPToken *token, NSError *error) {
    if (error) {
        // Handle error
        // [self handleError:error];
    } else {
        // Send off token to your server
        // [self handleToken:token];
    }
}];}

可以想象一个私有的'manager'类幕后的stripeView做了所有的工作（这个方法除了他们的委托回调之外）。

在你的情况下，这可能是一个相当好的模式。您可以将属性添加到要评估的数字的自定义视图中，将视图添加到层​​次结构中，然后创建在处理事物后自动回调的自定义委托;这将取代你的经理类回调。

最后的答案是，它很大程度上取决于业务逻辑和UIView之间的分歧对待它将提供多少。只要代码是可读的，可维护的，并且你有一些合理的模式可供遵循，我认为没有人会在iOS领域将你钉在十字架上。