2009-04-17 39 views

Trả lời

20

Đó là một câu hỏi khá trừu tượng, cho rằng cả hai thành phần & tập hợp là khá tương tự & thực sự chỉ khác nhau về khái niệm và không nhất thiết ở cấp mã. (nghĩa là bạn có thể xem xét một chiếc xe có Động cơ là thành phần, và Chó có bọ chét là tập hợp, nhưng không có gì ngăn bạn triển khai chúng theo cách tương tự nếu bạn mô hình hóa chúng bằng mã).

Tuy nhiên, nếu bạn muốn phá vỡ sự khác biệt & thử & buộc thêm quyết định thiết kế phần mềm để làm nổi bật những khác biệt Tôi đoán bạn có thể làm một cái gì đó như thế này ... chụp an example from Wikipedia:

Aggregation khác với bình thường thành phần ở chỗ nó không ngụ ý quyền sở hữu. Trong bố cục, khi đối tượng sở hữu bị hủy, thì các đối tượng được chứa. Trong tập hợp, điều này không nhất thiết phải đúng. Ví dụ: một trường đại học sở hữu nhiều bộ phận khác nhau (ví dụ: hóa học) và mỗi khoa có một số giáo sư. Nếu trường đại học đóng cửa, các phòng ban sẽ không còn tồn tại nữa, nhưng các giáo sư trong các phòng ban đó sẽ tiếp tục tồn tại. Do đó, một trường đại học có thể được xem như là một thành phần của các phòng ban, trong khi các phòng ban có một tập hợp các giáo sư. Ngoài ra, một Giáo sư có thể làm việc trong nhiều bộ phận, nhưng một bộ phận không thể là một phần của nhiều trường đại học.

Bạn có thể xây dựng mã này để đại diện cho nó (với càng nhiều dấu hiệu cho thấy giả tạo của thành phần/tập):

public class University : IDisposable 
{ 
    private IList<Department> departments = new List<Department>(); 

    public void AddDepartment(string name) 
    { 
     //Since the university is in charge of the lifecycle of the 
     //departments, it creates them (composition) 
     departments.Add(new Department(this, name)); 
    } 

    public void Dispose() 
    { 
     //destroy the university... 
     //destroy the departments too... (composition) 
     foreach (var department in departments) 
     { 
      department.Dispose(); 
     } 
    } 
} 

public class Department : IDisposable 
{ 
    //Department makes no sense if it isn't connected to exactly one 
    //University (composition) 
    private University uni; 
    private string name; 

    //list of Professors can be added to, meaning that one professor could 
    //be a member of many departments (aggregation) 
    public IList<Professor> Professors { get; set; } 

    // internal constructor since a Department makes no sense on its own, 
    //we should try to limit how it can be created (composition) 
    internal Department(University uni, string name) 
    { 
     this.uni = uni; 
     this.name = name; 
    } 

    public void Dispose() 
    { 
     //destroy the department, but let the Professors worry about 
     //themselves (aggregation) 
    } 
} 

public class Professor 
{ 
} 
+3

Cũ câu hỏi nhưng tôi stumbled khi nó, tôi sẽ chỉ đề nghị rằng nếu cục là phải chỉ tổng hợp, bạn có thể thực thi điều đó bằng cách có nó là một lớp lồng nhau bên trong trường đại học và làm cho nó riêng tư. Vì vậy, làm cho imposible cho bất kỳ nơi nào khác để thậm chí tuyên bố một Bộ và để lại các mối quan hệ cha mẹ/con rõ ràng. –

5

Vâng, trong một thế giới thu gom rác nơi mà tất cả các đối tượng được truy cập thông qua tài liệu tham khảo, sự khác biệt tinh tế (sở hữu) giữa phần nghiêm ngặt và tập hợp mờ một chút - vì vậy trong chung (khi sử dụng lớp) nó boils xuống một cánh đồng cho đối tượng hoặc bộ sưu tập khác:

class Building { 
    private readonly List<Room> rooms = new List<Room>(); 
    public IList<Room> Rooms {get {return rooms;}} 

    public Address Address {get;set;} 
    //... 
} 
class Address { 
    public string Line1 {get;set;} 
    public string PostCode {get;set;} 
    //... 
} 
class Room { 
    public string Name {get;set;} 
    public int Capacity {get;set;} 
    //... 
} 

Nếu tôi đã bị mất điểm, xin vui lòng làm rõ ...

Mọi thứ liên quan đến nhiều hơn khi bạn thảo luận struct s - nhưng nói chung khi nói về khái niệm OO, struct sử dụng được giới hạn trong lĩnh vực giá trị ...

Các vấn đề liên quan