类与类关系的UML图与代码表现（再讨论）

原文请看：http://www.iteye.com/topic/37302?page=1

我想对依赖(Dependency)和关联(Association)做一下补充。不正之处敬请指出。

[依赖]
对于两个相对独立的对象，当一个对象负责构造另一个对象的实例，或者依赖另一个对象的服务时，这两个对象之间主要体现为依赖关系。
[具体表现]
依赖关系表现在局部变量，方法的参数，以及对静态方法的调用 //除了这三种外我想还应该包括一些实例变量来实现，就像关联关系和聚合关系从语法上很难区分一样。依赖和关联在某些方面也很难从语法上去区分。
[现实例子]
比如说你要去拧螺丝，你是不是要借助(也就是依赖)螺丝刀(Screwdriver)来帮助你完成拧螺丝(screw)的工作

[代码表现]

你举的例子有道理~~
很高兴能跟你一起交流~~

人类的逻辑这种东西常常是不存在非常固定的格式的……

例如：

public class Person {
    
    private Eye eye;    
   
    public Eye getEye() {    
        return eye;    
    }    
   
    public void setEye(Eye eye) {    
        this.eye = eye;    
    }    
        
    public void see(){    
        this.eye.see();    
    }    
        
}   

Person和Eye之间应该算是[依赖]、[关联]还是[聚合]呢

依赖是最普遍的一种类与类之间的关系，类A不论以什么方法，只要能感知类B，就称类A依赖类B。依赖可以视为一种耦合，所以判定是否类A依赖类B最好的方法就是类B的存在或改变是否会影响类A。如果Eye不存在则Person将不能使用，当然Person依赖Eye。
关联表示的是类对另一个类的导航，就类A如果是类B的一个属性，则称类B与类A关联。Eye是Person的一个属性，Person当然与Eye关联，也称从Person导航到Eye，如果Eye也有Person属性，则称双向关联。
聚会表达的是一种整体与局部的关系，与关联不同的是，它只能是一个单向的关系，所以我们只能说Eye聚集于Person。在聚集关系中，代表整体的只能是1，但代表局部的可以是1，也可以是多

这样说行不行呢。假如同时有几种关系存在，就取关系最高的的那种。例如Dependency和Association同时存在的话就只说它们是Association的关系。就像我已经has你的，当然可以use你了。哈哈哈。我觉得这个准则可以说的通。不知各位还有没有其它意见。

我的看法和fangang基本一致，只是这一段，我觉得聚合应该是关联的一种特例，是表示整体/部分关系的关联。


Dependency比Association更概括一些，在这种情况下如果用Association就较准确，较能表达更多的语义

比较倾向聚合 语义上就是整体与部分关系