Question

对于两个对象之间的关联：

如果我有一个“Office”对象和一个“Person”对象。我会将其建模为一个关联，并且我已经提出了下面的示例代码作为执行它的方法。

但是看着它，我想要更多的东西可以让你更舒服。

第一个问题： Office对象实际上是一个类。我这样做是因为我只想要一个办公室 - 而且实例化它感觉不对。但我觉得我在描述一个实例化的人和一个“静态”类作为一个关联之间的关系时会遗漏一些东西？

第二个问题：我通过将其中一个对象传递给另一个对象来强制实现两个对象之间的关联。这是一种关联两个类的典型方式吗？

class Office
  @log = []
  @occupants = []

  def self.occupants
    @occupants
  end

  def self.log
    @log
  end

  def self.log_entry(person)
    if @occupants << person
      @log << "#{person.name} entered Office: #{Time.now}"
    end
  end  

  def self.log_exit(person)
    if @occupants.delete(person)
      @log << "#{person.name} exited Office: #{Time.now}"
    end
  end
end


class Person
  attr_accessor :name
  def initialize(name)
    @name = name
  end
end

zach = Person.new('Zach')
bill = Person.new('Bill')

Office.log_entry(zach)
Office.log_entry(bill)
Office.log_exit(zach)

puts Office.log

Answer 1

在UML思想中，关系是在实例之间而不是在类之间，而不是在类和实例之间。但有些情况下，在两个类之间或类和实例之间建立关系是很自然的。让我们以您的人/办公室为例。办公室类别可以命名为办事处和单一实例办公室因此，办公室和办公室之间会有一个自然的1：n关系。这类人可以被命名为人和一个人。因此，人与人之间会有一种自然的1：n关系。当您在UML图中的办公室和人员之间划一条线时，您将获得Office-Person关系。

“错误”的感觉来自上面的解释。您的办公室只有一个办公室。有一个链接到那个办公室的多个人实例完全是o.k。
对于1：1和1：N关系，如果一个实例知道另一个实例，通常就足够了。对于1：1，也可以轻松实现“双重”连接。在你的办公室：人际关系每个人“知道”它所属的办公室，这就是为什么你通过办公室实例让人记住。保留属于办公室的人员名单是可能的，但只要有一些方法可以查询“谁是属于这个办公室的人......”，这就是多余的。

Answer 2

除了使用术语关联之外，您的问题与UML无关。无论如何，我会尽力回答。

如果我理解正确，你希望你的Office类是一个单例（只有一个实例）。在UML中，您可以通过应用<<singleton>>构造型或从您调用Singleton的类继承来形象化（这有点是品味和环境的问题）。但是你总是需要一个实例，因为在现实世界中，一个类成为一个实例。只有那个有位和字节。这个课程就是它的概念。
从UML的角度来看，如何实现自己的关联是无关紧要的。它只是一个概念，两者之间存在某种关系。因此，无论您是通过new创建实例并持有该实例，还是将其传递都无关紧要。

如果您需要，我可以为您的类添加UML图。

不同的执行关联关系的方式

2 个答案: