【问题标题】:How should I build my object structure to balance collection classes and objects我应该如何构建我的对象结构来平衡集合类和对象
【发布时间】:2012-12-14 17:26:16
【问题描述】:

不太清楚如何解释这个,但这里是......

我正在为我的数据(在 Objective-C 中)构建一个对象结构以具有以下内容:

  • 一个Companies集合类
    • 其中包含许多Company 对象
      • 其中每一个都有一个Users 集合类
        • 其中包含许多User 对象

目标是获取对象数据(即companyIDcompanyName)和集合类(addCompany:deleteCompany:)的方法。

我真正想做的是构建类,以便我可以进行以下调用:

[[companies getCompanyWithID:1] addUserWithName:@"Duncan"];

但要做到这一点,我需要将方法 addUserWithName: 放在公司集合类上。

对我来说这没有意义 - 添加/修改/删除/获取用户的方法应该在 Users 集合类上,而不是在 Companies 集合类上。

如果我将这些函数放在它们相关的集合类上,那么我必须像这样编写相同的语句:

[[companies getCompanyWithID:1].users addUserWithName:@"Duncan"];

但它读起来不太好 - 因为它有一个讨厌的.users 潜伏在中间。

我是不是真的很笨,错过了一些明显的东西(我从未上过技术学校,所以很可能我错过了你们都知道的一些基本知识)。

任何帮助,非常感谢你们。非常感谢。

【问题讨论】:

    标签: objective-c oop object collections


    【解决方案1】:

    我可能误解了您的担忧,但我认为这不是问题。您的用户管理方法将使用Company,而不是Companies,这通常是可接受的模式。

    假设您有四个类:Companies/CompanyUsers/User。现在我们可以定义一个方法:

    @interface Companies
    - (Company *)companyWithID:(NSUInteger)id;
    @end
    

    这表示 Companies 类可以通过其 ID 让您返回 Company。 (旁注:在 Objective-C 中,我们很少使用 get... 前缀作为访问器方法 - 只需使用您想要的东西开始方法,在本例中为 company...。)

    从这里开始的传统做法是让您的 Company 类公开大量公共 API 来管理用户。你可能会这样做:

    @interface Company
    - (void)addUserWithName:(NSString *)name;
    @end
    

    反过来,Company 类将负责了解Users 集合的内部工作原理,包括根据需要对其进行修改。考虑到这一点,您可以编写:

    @implementation Company
    - (void)addUserWithName:(NSString *)name {
        [self.users addObject:name]; // self.users is of type `Users *`
    }
    @end
    

    这样,您可以避免将 .users 暴露给 Company 类的外部客户端 - 您只需转发 add... 消息。

    您甚至可以进一步采用这种策略,并说Users 集合类是一个实现细节,从不 需要向Company 类的客户端公开。相反,您可以根据更标准的系统集合对象为您的 Users 集合提供访问器:

    @interface Company
    - (NSSet *)users;
    - (void)addUserWithName:(NSString *)name;
    - (void)removeUserWithName:(NSString *)name;
    // and so on...
    @end
    

    这个思维过程的绝对极端会导致你完全摆脱你的Users 类,而只使用系统类来直接在你的Company 类上管理用户集合。一方面,这会让 Xcode 推断和建议(通过自动补全)非常适合这种模式的某些方法 - 请查看 Key-Value Coding Programming Guide 的 KVC compliance 部分以了解此类方法。另一方面,您的问题中可能没有显示更多复杂性,因此您的用例可能需要 Users 类。

    【讨论】:

    • 谢谢蒂姆。很棒的答案。我理解你所说的一切,这一切听起来都很棒,除了我不希望我的 Company 对象对我的用户负责。我知道你在暗示这是标准做法,但我真正想要的是让所有 USER 方法远离 COMPANY 方法,并且只将两者链接到一个地方。我将对此进行更多思考,但如果没有其他人用其他建议胜过您,我会将您标记为正确答案。
    猜你喜欢
    • 2013-05-27
    • 1970-01-01
    • 2011-12-22
    • 1970-01-01
    • 2011-04-21
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多