User permission settings and composite mode

• Address: http://www.cnblogs.com/WhiteCloud/archive/2006/07/31/464484.html
• Reference: http://www.cnblogs.com/WhiteCloud/services/trackbacks/464484.aspx

This design is very elegant. You can add group and user in group ...... The son has grandchildren and grandchildren, and the son has grandchildren ...... However, in practice, the relationship between users and user groups is not as simple as this. Whether a user has certain permissions depends on itself (rather than the group) do you have this permission explicitly? If you have this permission explicitly, it certainly has this permission; if you explicitly refuse, it certainly does not have this permission; if you do not have this permission or reject it, in other words:This permission is inherited from the user group only when a user does not explicitly possess or reject a permission..

In this regard, the "user" and "User Group" classes have different behaviors. Simply put, the Group class only has grantpurview behavior, the user class also has the denypurview and clearpurview actions. When you use them, you must know the difference between group and user and the specific subclass of the group. The intention of applying the composite mode is to "ensure consistency in the use of a single object and a composite object", while group and user are completely different classes, if users must find out which specific subclass they are using, there is no consistency. In other words, if the userbase interface also has denypurview and clearpurview, it must be a degradation function in the implementation of the Group. (The addchild method in user throws an exception, which can be weighed in terms of security and transparency ).

Ah, let's say it again. It's just a digress. It doesn't mean porn.