今天刚刚看as cookbook的第一部分，custom classes（自定义类），看到里面讲了inheritance（继承）和composite（组合），前一阵子一直听老公在我面前讲这两者的不同，今天总算看到两者的专业解释和适用的情况：
"Is a" relationships are often inheritance relationships. As an example, consider an application that manages a library's collection.【“是”关系常用于表达继承关系，例如，我们认为某个应用管理着图书馆里所有的收藏】
"Has a" relationships are composition relationships in which a class declares a property. Most classes use composition. Oftentimes composition can be implemented in such a way that it achieves the same results as inheritance with greater flexibility (yet generally requiring more code). For example, a book is not an author, but it has an author (or authors).【“有”关系是把某一个类作为另一个类的某一属性的组合关系。很多类都使用这种关系。通常组合常常用于实现继承关系所能表达的含义而且更具有灵活性（但是需要相对多的代码），例如，一本书不能代表一个作者，但是书可以“有”作者（或很多作者）】The "Is a" and "Has a" test is helpful, but not always definitive in determining the relationship between classes. Often composition can be used even when inheritance would be acceptable and appropriate. In such cases the developer might opt for composition because it offers an advantage or flexibility not provided by inheritance. Furthermore, there are times when a class may appear to pass the "Is a" test yet inheritance would not be the correct relationship. For example, the library application might allow users to have accounts, and to represent the user, you would define a User class. The application might differentiate between types of users; for example, administrator and standard users. You could define Administrator and StandardUser classes. In such a case, the classes would appear to pass the "Is a" test in relation to User. It would seem to make sense that an Administrator is a User. However, if you consider the context an Administrator isn't actually a User, but more appropriately an Administrator is a role for a User. If possible, it would be better to define User so it has a role of type Administrator or StandardUser.【“是”和“有”的关系的理解比较有助但是不能全靠他们来决定如何组织类之间的关系。在继承关系会被接受或者合适的情况下，开发人员可能还会选择具有有利和灵活特征的组合关系，因为继承无法满足这两点。此外，又是当一个类以“是”的形式被传递给另一个类是，不表示这种继承是正确的。例如，图书馆应用程序里可以允许用户有帐号来表示用户，那我们会定义为一个“User”类，应用程序会把区分不同的用户；如管理员和标准用户。我们可能定义“Administrator”和“StandardUser”两个类。在某种情况下，这两类会以“是”的形式给“User”，好像看起来Administrator就是一个“User”，但是，如果你了解环境的话就明白其实不然，而“Administrator”更确切的是“User”的一种角色，或者我们可以更好的认为“User”有两种角色：“Administrator” 和“StandardUser”】 其实我觉得这本书讲的也比较细致了，其实在大谈设计模式的今天，有一类人一说oo即使继承和封装，却不知道我们需要学习和尝试的东西其实很多，本文共享给大家，相互探讨！
今天刚刚看as cookbook的第一部分，custom classes（自定义类），看到里面讲了inheritance（继承）和composite（组合），前一阵子一直听老公在我面前讲这两者的不同，今天总算看到两者的专业解释和适用的情况：
"Is a" relationships are often inheritance relationships. As an example, consider an application that manages a library's collection.【“是”关系常用于表达继承关系，例如，我们认为某个应用管理着图书馆里所有的收藏】
"Has a" relationships are composition relationships in which a class declares a property. Most classes use composition. Oftentimes composition can be implemented in such a way that it achieves the same results as inheritance with greater flexibility (yet generally requiring more code). For example, a book is not an author, but it has an author (or authors).【“有”关系是把某一个类作为另一个类的某一属性的组合关系。很多类都使用这种关系。通常组合常常用于实现继承关系所能表达的含义而且更具有灵活性（但是需要相对多的代码），例如，一本书不能代表一个作者，但是书可以“有”作者（或很多作者）】The "Is a" and "Has a" test is helpful, but not always definitive in determining the relationship between classes. Often composition can be used even when inheritance would be acceptable and appropriate. In such cases the developer might opt for composition because it offers an advantage or flexibility not provided by inheritance. Furthermore, there are times when a class may appear to pass the "Is a" test yet inheritance would not be the correct relationship. For example, the library application might allow users to have accounts, and to represent the user, you would define a User class. The application might differentiate between types of users; for example, administrator and standard users. You could define Administrator and StandardUser classes. In such a case, the classes would appear to pass the "Is a" test in relation to User. It would seem to make sense that an Administrator is a User. However, if you consider the context an Administrator isn't actually a User, but more appropriately an Administrator is a role for a User. If possible, it would be better to define User so it has a role of type Administrator or StandardUser.【“是”和“有”的关系的理解比较有助但是不能全靠他们来决定如何组织类之间的关系。在继承关系会被接受或者合适的情况下，开发人员可能还会选择具有有利和灵活特征的组合关系，因为继承无法满足这两点。此外，又是当一个类以“是”的形式被传递给另一个类是，不表示这种继承是正确的。例如，图书馆应用程序里可以允许用户有帐号来表示用户，那我们会定义为一个“User”类，应用程序会把区分不同的用户；如管理员和标准用户。我们可能定义“Administrator”和“StandardUser”两个类。在某种情况下，这两类会以“是”的形式给“User”，好像看起来Administrator就是一个“User”，但是，如果你了解环境的话就明白其实不然，而“Administrator”更确切的是“User”的一种角色，或者我们可以更好的认为“User”有两种角色：“Administrator” 和“StandardUser”】 其实我觉得这本书讲的也比较细致了，其实在大谈设计模式的今天，有一类人一说oo即使继承和封装，却不知道我们需要学习和尝试的东西其实很多，本文共享给大家，相互探讨！
.: 
