Design issues
Hello there,
I have 4 classes.
1. User
2. Client
3. UserManager
4. ClientManager
User is an abstract class and Client inherits from User. Therefore, a Client is a User.
UserManager is solely responsible for User objects management. It handles adding, removing, editing and getting all Users. Moreover, UserManager internally caches all Users objects using a List.
In structure sense, ClientManager works pretty much the same way as UserManager. Client objects are cached internally having the same functionalities like UserManager; adding, removing, etc.
The problem is caching Users and Clients result in duplicate data. Lets say User has the following properties:
1. String userName
2. String password
Since Client inherits from User, Client possesses these properties as well. Therefore, both caches store the same data.
What I hope to resolve:
Is there any way I can manage only set of User data? This can really be a big problem if I want to index these data.
Perhaps anyone can recommend a design pattern or something to effectively manage a set of data?
Thanks in advance.
Regards
# 1
Hi,I sounds like you have used inheritance where you shouldn't. Client should not inherit from User. The inheritance is the reason that you now have an odd design.Kaj
# 2
What you can do if you want to keep your design is to make UserManager an abstract class, and let ClientManager extend it.(But as I said, I wouldn't let Client extend User)Kaj
# 3
I choose to allow Client to inherit from User because a Client is a User as well. All Clients need to log on using a set of principal and credentials.
Sorry I didnt mention this in my previous post. UserManager is an abstract class and ClientManager inherits from UserManager. UserManager is controlled by an interface. I was planning to make use of Decorator, where each child adds on its own functionalities aside from whats given by UserManager.
Message was edited by:
Parker_
# 4
I don't understand why you get duplicate data. You cannot create an instance of a User object, nor an instance of a UserManager. So you'll only be working with Client and ClientManager objects.
# 5
> I choose to allow Client to inherit from User because
> a Client is a User as well. All Clients need to log
> on using a set of principal and credentials.
Yes, but there are other types of users as well? Your design does not allow one person to "have" more than one type. You can't create a user which is e.g developer and administrator. I would say that a user has types. That is, a user should use aggregation.
Kaj
# 6
Let me give an example.
Lets say if I want to add a new Client. I would use ClientManager to add this new Client.
ClientManager.register(Client newClient)
Internally, UserManager does its own caching and indexing of User objects, like ClientManager, caching and indexing of Client objects.
Since I am using Decorator, UserManager shares the same interface as ClientManager.
UserManager.register(User newUser)
register() from UserManager will be called first when I invoked ClientManager.register().
Invoking register() triggers the indexing and caching mechanism. Which means, I am indexing userName and password in UserManager and indexing the inherited userName and password again in ClientManager.
I can definitely change Client not to inherit from User but that will leave Client without a set of principal and credentials.
# 7
Good point from Kaj... One of the key design principles is "Favor object composition over inheritance".
# 8
Yes I had that in mind as well. Aside from Client, there will be other Users as well such as Administrator, Guest, CSO, Root, Operator, etc. All these types share one abstract class User, having a userName and password.
# 9
Do you need different types of management to work with the Decorator pattern? I can understand that you want to decorate your users, but why do you use that pattern for you management?
# 10
I hope this doesnt turn out to be an anti-pattern issue...
Decorator helps in adding responsibilities to children of UserManager. UserManager has its own mechanism to register a new User, say to a database.
By using Decorator, ClientManager can define its own registration mechanism and at the same time use UserManager's registration mechanism.
# 11
Ok, I can agree with that, but if you have a good reason to have different registration mechanisms, then I guess you'll have to go with separate cache lists as well.. But the entries in your lists will be references to the same objects. Besides, if you have seperate register methods, you'll decorate the unregister methods as well, so they'll take care of the integrity of the different lists... Maybe there was no problem in the first place.
# 12
Live with seperate cache lists? Hmm..i dont know.. Experience has taught me that duplicate data spells disaster...Back to the drawing board I guess...Anyway.. thanks Peetzore. Appreciate it!!! =)
