rcw*_*cw3 1 cocoa design-patterns objective-c
例如,我有窗口(非文档模型) - 它有一个与之关联的控制器.在这个窗口中,我有一个列表和一个添加按钮.单击添加按钮将显示另一个"详细信息"窗口/对话框(带有关联的控制器),允许用户输入详细信息,单击确定,然后将项目传播回原始窗口的列表.显然,我会有一个底层模型对象,它包含这些实体的集合(让我们将单个实体称为实体以供参考).
可以想象,我只有一个主窗口,所以我可能只有一个实体集合.我可以将它藏在主窗口的控制器中 - 但是如何将它传递给细节窗口？我的意思是,我可能不希望传递这个集合 - 难以阅读/维护/多线程.我可以传递一个对父控制器的引用并使用它来访问集合,但这似乎也闻起来.我可以将它存储在appDelegate中,然后通过[[NSApplication sharedApplication]委托]将其作为"全局"变量访问 - 这似乎有点过分,考虑到应用委托与模型没有任何关系.另一个全局变量样式可能是一个选项 - 我可以使Entity类具有用于集合的单例工厂和用于访问集合的类方法.这似乎比appDelegate更大的滥用 - 特别是考虑到Entity对象和所述实体的集合是两个独立的问题.我可以创建一个EntityCollection类,它具有单例工厂方法,然后是对象与集合交互的方法(或者分成真正的工厂类和集合类,以获得更多的OO优点并轻松替换测试对象).如果我使用的是NSDocument模型,我想我可以将它存放在那里,但这与在应用程序委托中存储它没有多大区别(尽管NSDocument本身看起来似乎以某种方式表示模型).
我最近在服务器端花了很多时间,所以我没有必要对付客户端很多,当我有,我只是粗暴强迫解决方案.最后,有十亿种方法可以为这只猫提供皮肤,看起来它们都不是非常干净或漂亮.普遍接受的Cocoa程序员的做法是什么？或者,更好的是,这样做的最佳方式是什么？
我认为你的概念问题是你正在考虑将接口作为应用程序的核心,将数据模型视为必须找到一个可以在某处填充的地方.
这是倒退.数据模型是程序的核心,其他所有内容都被移植到数据模型中.该模型应该封装可以对数据执行的所有逻辑操作.接口,GUI或其他方式仅向请求特定动作的数据模型发送消息.
从这个概念开始,很容易看出普遍可访问的数据模型不是草率设计.由于模型包含用于更改数据的所有逻辑,因此您可以使用任意大量的接口来访问数据,而不会使数据变得混乱或代码复杂,因为模型仅根据其自己的内部规则更改数据.
完成通用访问的最佳方法是创建一个单例生成类,然后将该类的标头放在应用程序前缀标头中.这样,应用程序中的任何对象都可以访问数据模型.
Edit01:
让我澄清裸全局变量和全局可访问类封装数据模型之间的重要区别.
从历史上看,我们将全局变量视为糟糕的设计,因为它们只是原始变量.代码的任何部分都可以随意改变它们.这种裸露导致了明显的问题,你必须不断防止一些代码的流浪片段改变全局,然后降低应用程序.
但是,在基于类的全局变量中,全局变量由封装类实现的逻辑封装和保护.这种封装意味着虽然代码的任何杂散片段都可能尝试改变类中的全局变量,但只有封装类允许更改时才能这样做.自动验证降低了代码的复杂性,因为所有验证逻辑都驻留在一个单独的类中,而不是在数据可能被操纵的任何随机位置遍布应用程序.
您可以创建强大且通用的数据验证和管理,而不是像裸全局变量那样创建弱点.如果您发现数据管理存在问题,则只需将其修复到一个位置即可.一旦你有一个正确配置的数据模型,应用程序的其余部分变得非常容易编写.