Tại sao mỗi widget cần một tham chiếu đến cha mẹ của nó trong một hệ thống widget đơn giản?

Tôi đang làm việc trên một hệ thống widget đơn giản (một cửa sổ, kích thước cố định). Mỗi widget được cha mẹ của nó (tức là widget chứa nó) được truyền vào hàm tạo của nó - ngoại trừ widget gốc, mà tôi gọi là Screen .

Tôi có một số nghi ngờ nếu cách tiếp cận đó có ý nghĩa. Tôi đã làm điều đó bởi vì hầu hết các hệ thống widget mà tôi đã sử dụng trước đây đã làm điều đó (Qt, GTK, ...), nhưng tôi nhận ra rằng chúng khá phức tạp hơn so với của tôi:

• Tôi không có kích thước cửa sổ
• Tôi không có kế hoạch kích thước container dựa trên kích thước của con cái họ
• Tôi không nghĩ rằng tôi cần nó để quản lý bộ nhớ (tôi đang sử dụng C ++), thay vào đó tôi có thể sử dụng các con trỏ được chia sẻ (về cơ bản cách thức hoạt động của nó trong Java)

Có bất kỳ lý do tại sao một widget sẽ cần một tham chiếu đến cha mẹ của nó?

Đây là một tái cấu trúc lớn để thay đổi điều này. Vì vậy, trước khi tôi tiếp tục triển khai các container và bố cục, tôi muốn có một ý tưởng tốt về việc tôi có cần cha mẹ đó hay không.

Chỉnh sửa: Xin lưu ý rằng cha mẹ dù sao cũng biết tất cả con cái của mình, tôi chỉ tự hỏi liệu con cái có cần biết cha mẹ không.

Như bạn đã chỉ ra, bản thân đứa trẻ hiếm khi cần tiếp cận cha mẹ, miễn là cha mẹ làm tất cả công việc và theo dõi con cái. Tuy nhiên, cổ điển getParentlà hữu ích nhất khi bạn sử dụng khung từ bên ngoài.

Kịch bản

Một thao tác đơn giản có thể gây ra sự cố như sau: đưa ra hai vật dụng cụ thể nằm ở đâu đó trong cây widget tổng thể của bạn và trường hợp sử dụng yêu cầu bạn trao đổi hai cái này, việc hoán đổi hoạt động như thế nào?

Cách 1: Nói với trẻ

Nói với con của bạn để swap(withOtherChild). Nhưng trao đổi liên quan đến việc cập nhật cơ sở hạ tầng con cái của cha mẹ theo một cách nào đó. Vì con bạn không biết cha mẹ của nó, làm thế nào để bạn đạt được điều này?

Cách 2: Nói với bố mẹ

Nói với cha mẹ của một đứa trẻ để loại bỏ nó và thêm cái khác. Oh chờ đợi, cùng một vấn đề. Bạn chỉ có những đồ vật trẻ em và không có getParentnhững thứ đó.

Cách 3: Công việc lẩm cẩm

Là một tùy chọn cuối cùng, bạn có thể duyệt qua toàn bộ cây widget của mình để tìm cha mẹ hasChild(x)và một với hasChild(y)và sau đó quay lại tùy chọn 2.

Giải pháp

Bạn nên giữ cha mẹ nếu bạn muốn xây dựng các cây widget lớn và thực hiện các hoạt động yêu cầu di chuyển vị trí của widget trong cây. Nếu cây widget của bạn rất nhỏ hoặc chỉ có độ sâu rất nhỏ, nhưng bộ truy cập nhanh hasChild, thì Tùy chọn 3 có thể được chấp nhận cho bạn và bạn có thể bỏ qua tham chiếu chính.

Tài liệu tham khảo trong các cơ sở dữ liệu nói chung

Những gì bạn đang dự định làm ở đây là xây dựng cơ sở hạ tầng cho cây. Chúng ta hãy xem xét đơn giản hóa và để tranh luận cho rằng mọi widget chỉ có thể có một con. Tất nhiên, kết quả là một danh sách và câu hỏi của bạn bây giờ trở thành "tôi nên có một danh sách liên kết đơn hoặc liên kết đôi?".

Và cũng giống như danh sách, không có câu trả lời chắc chắn, mà chỉ có ưu và nhược điểm. Rõ ràng ưu điểm cho liên kết đơn (nghĩa là không có tham chiếu cha) là a) dễ thực hiện hơn và b) ít bộ nhớ hơn. Nhưng nhược điểm bao gồm a) một số hoạt động trở nên chậm vì chúng phải đi qua cấu trúc và b) không dễ dàng truy cập vào các hoạt động đó có thể có nghĩa là cơ sở hạ tầng khó sử dụng và c) nó sử dụng nhiều bộ nhớ hơn.

Mặt khác, biến thể liên kết đôi, tức là với tham chiếu cha, khá nhiều đảo ngược những ưu và nhược điểm này.

Tuy nhiên, về mặt thư viện / khung GUI, các giới hạn bộ nhớ thường không phải là vấn đề cấm các con trỏ cha. Nếu bạn loại trừ điều đó và nhận ra rằng đó là một thư viện / khung, và do đó, khó có thể thực hiện được, nhưng dễ sử dụng, thì về cơ bản bạn sẽ loại trừ những ưu điểm trên của cách tiếp cận liên kết đơn.

Tôi không nhận thức được đặc thù của dự án của bạn, vì vậy tôi muốn không nói với bạn để giữ tài liệu tham khảo cho phụ huynh, vì một số lý do trên của tôi có thể không áp dụng trong trường hợp của bạn. Tuy nhiên, nói chung, tôi coi các tham chiếu cha trong cơ sở hạ tầng widget là đáng giá vì những lý do trên.

Trong hầu hết các trường hợp này, có khá nhiều giao tiếp đang diễn ra giữa cha mẹ và con cái trong trường hợp có sự kiện, tín hiệu hoặc thay đổi trạng thái (hoặc đơn giản là để tiêu diệt trẻ em khi cần thiết). Ví dụ, một hộp nhóm có thể xử lý các nút radio có chứa nó để đảm bảo chỉ một trong số chúng được "bật" tại một thời điểm nhất định.

Bạn có thể hoặc không thể có kế hoạch để có chức năng của loại này. Cá nhân tôi sẽ nghi ngờ nếu một hệ thống phụ tùng mà không có nó đáng giá thời gian vì nó sẽ không cung cấp nhiều. Nhưng sau đó tôi chỉ đơn giản là sử dụng một trong những giải pháp hiện có.

Tôi sẽ nói rằng, khi những đứa trẻ biết cha mẹ của chúng, một vật dụng và tất cả tổ tiên của nó tạo thành một chuỗi trách nhiệm . Một ví dụ điển hình là một sự kiện chuột được nhận bởi một tiện ích: tiện ích có thể tiêu thụ sự kiện (và phản ứng tương ứng) hoặc truyền sự kiện cho cha mẹ của nó, người có thể tiêu thụ hoặc truyền cho cha mẹ của nó, v.v ...

Trong trường hợp của Qt, mỗi widget được cung cấp bởi cha mẹ của nó bởi hàm tạo và điều này chỉ ra rằng widget được sở hữu bởi cha mẹ. Cụ thể, việc xóa cha mẹ sẽ kích hoạt việc xóa widget.