Tutorial :Patterns for the overlap of two objects


I'm sure this has already been asked and answered so I apologize in advance for that but I'm not figuring out the correct keywords to search for. Searching for "Pattern" hits way too many Q & A's to be useful.

I'm working on a regression testing app. I'm displaying a form on the screen and according to which user is logged in to the app some of the fields should be read-only. So I can abstract a field object and I can abstract a user object but what pattern should I be looking at to describe the intersection of these two concepts? In other words how should I describe that for Field 1 and User A, the field should be read-only? It seems like read-only (or not) should be a property of the Field class but as I said, it depends on which user is looking at the form. I've considered a simple two-dimensional array (e. g. ReadOnly[Field,User] = True) but I want to make sure I've picked the most effective structure to represent this.

Are there any software design patterns regarding this kind of data structure? Am I overcomplicating things--would a two-dimensional array be the best way to go here? As I said if this has been asked and answered, I do apologize. I did search here and didn't find anything and a Google search failed to turn up anything either.


Table driven designs can be effective. Steve Maguire had few nice examples in Writing Solid Code .

They are also a great way to capture tests, see fit .

In your case something like:

Field1ReadonlyRules = {      'user class 1' : True,      'user class 2' : False  }    field1.readOnly = Field1ReadonlyRules[ someUser.userClass ]  

As an aside you probably want to model both users and user classes/roles/groups instead of combining them. A user typically captures who (authentication) while groups/roles capture what (permissions, capabilities)


At first blush it sounds more like you have two different types of users and they have different access levels. This could be solved by inheritance (PowerUser, User) or by containing a security object or token that sets the level for the user.

If you don't like inheritance as a rule, you could use a State pattern on the application, Decorate the user objects (Shudder) or possibly add strategy patterns for differing security levels. But I think it's a little early yet, I don't normally apply patterns until I have a firm idea of how the item will grown and be maintained.

Note:If u also have question or solution just comment us below or mail us on toontricks1994@gmail.com
Next Post »