在构造函数中传递控制器总是不好的做法吗？

Posted 2023-03-13

【中文标题】在构造函数中传递控制器总是不好的做法吗？

【英文标题】：Is passing a controller in a construtor always a bad practice?

【发布时间】：2013-02-14 02:44:30

【问题描述】：

我偶尔会通过传入视图控制器实例本身来从我的视图控制器实例化一个类，以便我创建的对象可以调用控制器的方法来更新视图。

这总是、经常或从不是一种不好的做法吗？

具体来说：

ViewController.h 有

-(void)updateButtonValue:(NSString*)value;

MyObject.h 有

-(id)initWithViewController:(ViewController*)aViewController;

我从我的视图控制器实例化该类：

[[MyObject alloc] initWithViewController:self];

因此允许 MyObject 实例通过如下简单调用更新我视图中的按钮值：

MyObject.m

[self.viewController updateButtonValue:@"example"];

这似乎并不理想，因为我传递给 MyObject 的内容（视图控制器本身）比它应该需要的多得多，但它肯定是快速且实用的。如果有更简洁的方法，例如依赖协议，也很简洁，一个简短的代码示例将不胜感激。

【参考方案1】：

传递一个类类型的指针总是不好的做法，因为您将对象紧密耦合在一起（每个对象都需要知道另一个对象的类，它们也可能是一个对象）。这就是委托模式的用途。它最大限度地减少了 MyObject 所需的信息（至少，只不过是一个指针类型 id - 最好是由 MyObject 指定的协议，以提供一些行为保证）

所以翻译你的例子

MyObject.h

替换...

-(id)initWithViewController:(ViewController*)aViewController;

与...

-(id) init; 

（如果您没有进一步的理由覆盖，则可以省略）

还有……

@property (nonatomic, weak) id delegate;

myViewController 中的实例化（确实需要#include MyObject）...

MyObject* object = [[MyObject alloc] init];

紧随其后

object.delegate = self;

（请注意，object 获得指向 myViewController 的指针，无需了解任何其他信息）

现在您可以在object 内部执行此操作：

 [self.delegate updateButtonValue:@"example"];

然而 ...您需要确保您的代表可以收到消息updateButtonValue：

为此，您在 MyObject.h 中声明一个带有此方法签名的协议

@protocol MyObjectDelegate

  - (void) updateButtonValue:(NSString*)string;

@end

在你的 viewController 中，使用接口行中的 声明你遵守这个协议

@interface ViewController <MyObjectDelegate>

（这没什么大不了的，ViewController 已经需要#include MyObject 来分配/初始化它，所以不需要更多信息来执行此操作）

然后扩展您的财产声明：

@property (nonatomic, weak) id <MyObjectDelegate> delegate

现在您已经为编译器提供了足够的信息，以确保您只能传递符合要求的消息。这里的绝妙之处在于，MyObject 可以自信地将消息传递给 MyViewController，而无需了解有关 MyViewController 的任何信息，除了通过委托指针到达它之外。

【讨论】：

我希望我能投票两次。清晰详细，准确回答我想知道的。注意：在我的代码可以正常工作之前，我需要按照您的建议一直声明协议。没有它，我确实可以调用我的 updateButtonValue 但视图本身没有更新。不完全确定为什么。

绑定是一种可能的设计模式，在这里会有用吗？例如，在控制器层次结构（AppDelegate 或 NSDocument）中较高的对象中，您可以绑定到较低的值，并在观察到的属性发生更改时调用自定义方法。只是想知道，因为我经常使用委托模式，但我开始在我的代码中使用绑定。