Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

In a simple application I am creating there are Admin and users where admin can create users. Right now I am creating Classes that encapsulate database CRUD calls with methods.

For example: adminStore.CreateUser(userObject)

will persist that user object into the Database and return the object. I am now confused as to which DataAccess entity I need to attach methods like these. Doing them on adminStore will make them sensible in sense developer would understand that admin is creating the user and has access role. But from another perspective the below to sounds logical.

like: userStore.CreateUser(userObject);.

So my questions would somewhat sound like a Api design,Class design question but I would like to know which if the below is the right one.

1 UserStore.CreateUser(userObject)

2 AdminStore.CreateUser(userObject)

Update: Here is what i came up with later after viewing the answers.

User { Name ,Email, Password }

Admin:User,IImplementsAdmin { FlagPost() etc etc }

AdminStore { CreateUser(), SetUserStatus() }

share|improve this question
add comment

2 Answers

up vote 1 down vote accepted

Doing them on adminStore will make them sensible in sense developer would understand that admin is creating the user and has access role.

The business policy has little to do with these design decisions. Policies change frequently. Just avoid creating circular dependencies and it will work out. For example, if createUser calls methods in AdminStore, and AdminStore is already dependent on UserStore, then put the method in AdminStore. If createUser has no dependency on AdminStore, or if UserStore already depends on AdminStore, then put the method in UserStore.

I have found that writing the code test-first leads me to a workable design almost automatically. If I wrote a unit test for createUser, and didn't need to instantiate AdminStore to define the test, that would be a strong sign that the createUser belongs in UserStore and not AdminStore.

Don't dwell too long on these little design decisions. Just pick one, and get back to work. Later you may see that it would be better the other way. No problem. It's just code. Change it.

When you see a beautifully designed application or library, it is almost certainly the result of a lot of refactoring, and not the result of some brilliant initial design.

share|improve this answer
    
thank you for putting into my shoes:) –  Deeptechtons Oct 4 '11 at 1:40
    
+1 for many practical comments specially about the business policy change...It would be interesting to discuss how to assign concrete class responsibilities and 'virtual' responsibilities that could change when business rules change... –  Emmad Kareem Oct 4 '11 at 3:21
add comment

I am not sure about your object model, but I would create a user class and an 2 other classes inheriting from user. One class would be the admin class and the other is the regular user class. A method like CreateUser would be the responsibility of the admin class that inherits from the user class. Optionally, you could choose to make the super user class an abstract class.

A side note: You need to consider here what if an admin becomes a regular user and what if regular user becomes an admin? Your model should accommodate for this.

share|improve this answer
    
votes up, really interesting technique u explained there –  Deeptechtons Oct 4 '11 at 1:40
    
@Deeptechtons thanks, I hope it is the correct approach (at least from a theoretical point) –  Emmad Kareem Oct 4 '11 at 2:00
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.