OO - Class design confusion :confused:

[Shahfazal Mohammed]

Hello everyone-
dunno if this is the forum i should be posting to, but the forum says OO so ... but anyway we are designing a J2EE application (somethign about searchign for properties in an area) which has four major players
1. The person that searches for properties
2. the person that adds properties (registers with the system)
3. the person that is a state-employed economic development professional for a particular area
4. a basic onsite-administrator to watch over the system. (someone like a super-user, can)
Requirements-wise hierarchy: Admin -> EDP -> Realtor -> Site Selector
the Admin is at the top of the tree, enjoying all the privileges of those under her/him.
in the above list, 4 can do what all 3,2,1 can do and 3 all that 2,1 and 2 all that 1 can do (a project requirement). Now my first approach was to model a *Manager for each of the above functionality, import a particular *Manager, and use the method i need.
Scenario: like when teh administrator (AdminManager) wants to search for a property, u use the search method of the site selector (SearchManager).
But now, my project manager has come up with a class-design model in which say the AdminManager extends the EDPManager which the RealtorManager(whatever) which extends the SearchManager. This way for the above scenario, the AdminManager will have inherited the search() method of the SearchManager.
Design-wise hierarchy: AdminManager -> EDPManager -> RealtorManager -> SearchManager
now, the SearchManager is at the root of the tree with the AdminManager all the way down, leaf-node, whereas in the requirements-hierarchy the Admin was at the root.
My problem is- i'mhaving trouble in the way the thing is reversed .. is that what OO is? i mean.. inheritance - subclassing .. the lower down the inheritance tree you are, the more functionality you have, that makes sense actually but i feel kinda uncomfy that the AdminManager is at the leaf-node level class-wise whereas he/she is at the root requirements-wise , i guess that's OO after all, more specialization, more levels down the tree. but is more specialization the same as more privileges in the system??(according to the project requirements).
Am sorry if this is too little information/explanation but can explain more once anyone gets what i'm saying and posts back.
-hoping to see a reply

[Junilu Lacar]

I don't think using inheritance the way you have it now is appropriate. See this article by Martin Fowler: http://www.martinfowler.com/apsupp/roles.pdf
[ March 26, 2004: Message edited by: Junilu Lacar ]

[Stan James]

I like your first two actors because you describe what they do. The third one is a place in the food chain in the world, but doesn't tell me what they do. The last one is a bit of both. When finding actors, focus on the ROLE not the person you know will do the job or the job title. A human can play any number of roles. Darned users make everything so hard!
I've given up trying to put roles & priviliges into hierarchies. There are always exceptions, somebody who can do A and D but not B and C in between. It's also a problem is to make somebody's role their Java class. What if they change roles? Maybe somebody gets prmoted. Or an administrator wants to look for a property for herself? You can't change an object's class in flight. You can easily change their roles or give them multiple roles if you mapped it all right. The whole notion of users - groups - roles - permissions is pretty well evolved and is used in some variation in many places.
As an alternative, see if patterns like Strategy or State makes sense. If you can say "While I'm doing this role, I can do these things in this way" maybe you can make a special class for exactly that behavior and a Person object can use that behavior for a while, and switch to another behavior class at a later time.
We often encourage people to let patterns emerge. Work on your code until one day you say "Hey, this is turning into State!" and then see the pattern book for conventional names, anything you might have missed. And here I go pointing you toward the patterns first. To let me off the hook, tell me you have some code and it's kinda starting to look like one of those
Hope that helped!

[Shahfazal Mohammed]

Hey-
thanks for your input. the link was very informative. but during a meeting w/ my team, the lead programmer was saying that for our web application, it was not really necessary that we use the hierarchy as designed and the *Manager would be separate entities. the AdminManager would just import the SearchManager and use the methods within, which was more comforting to me. not now, but maybe when it's a really complex system with roles/states adn stuff like that, we'd look into patterns and follow them perhaps.
but i'd definitely like a definitive answer to this u know

[Stan James]

Ah, I first took your class hierarchy to represent people. We have a "user" class that represents all users of the system, no hierarchy of classes to match hierarchy of job titles. Roles & permissions control what each user can do.
But now I think you're maybe showing us service classes that actually do the search work or do the admin work. Those should also definitely not be in a hierarchy. Services can certainly call each other.
But I'm not sure they need to. Why would an admin service call a search service? Can you describe your architecture a bit ... user clicks search ... what happens?