Mapper Pattern

[Itshim]

For an application I'm working on, I have two classes which represent a 'user' one controls all the db functionality, and the other provides access to the 'current user' attributes, or is a blank slate to create a new user. Simply the classic mapper pattern.

Now...I have an interface which needs to provide a select menu of all the 'users', based on their user 'rank'. This is a simple select query to gather a list of users, but my problem is that I have no idea where to put the method.

It doesn't really fit into either of the classes, because they represent one user, but the select statement deals with the same db tables, and it seems a little crazy to create another class for this method.

 

[jpadie]

i don't really use OO that much. i think i'm alone in the world in thinking that procedural code is easier to keep in the mind and maintain.

but ... isn't it a more logical way to think about it that the class you are creating is for users (plural, i.e. as a class) and that the methods within the class instantiate objects containing one or more users?

another way of looking at it might be that you're trying to be too purist and should shove the method into the user class ;->

 

[Itshim]

isn't it a more logical way to think about it that the class you are creating is for users (plural, i.e. as a class)...

You are correct, this is the approach I decided to take. I just didn't want to add too much intelligence into the code, like the saying goes 'Keep It Simple Stupid' (at least the way I've heard it)

another way of looking at it might be that you're trying to be too purist and should shove the method into the user class ;->

I hear you...In the past I have always been able to keep the data manipulation classes organized and to the point, but the extra methods used to fill out interfaces were thrown in here and there (where ever it seemed logical at the time). Needless to say by the end of the project I had all these extra methods scattered throughout the code, and it just wasn't working for me any more.

Thanks for the advice...
Itshim

 

[theEclipse]

jpadie -

I am with you on the use of procedural code in php. Not that OO programming doesnt have its benefits....because it does....but I have never been in a situation in web programming that required the use of it. I think that the reason for that is because most of what I would use OO for is already done by the PHP engine running multiple scripts at the same time.

Robert

 

[Itshim]

Both methods (OOP and procedural) have there place. OO code is never necessary, basically it's a matter of code organization (in PHP).

I use procedural code when I'm scripting something small. OOP on a small project is like using a sledge hammer on a finishing nail.

On larger projects I find it easier to organize and maintain if I use clear patterns during development, which basically leads to OOP. I have also found that large projects which are well written and organized in procedural code are OO designs without a 'class' wrapping the functions.

 

[sleipnir214]

OOP is useful in large projects because it allows programmers to bundle code into more easily-digested bites. Whether you use PHP's class functionality or not, you're already doing this bundling in web applications -- that more easily-digested bite is called a "page", which (with its accompanying script to process the data input on the page) contains the datastore and program code.

Where I find OOP code most useful with web applications and PHP is in code portability. The functionality of something useful like PHPMailer can be easily added to an existing function with little more fanfare than an include() or require() invocation.





Want the best answers? Ask the best questions! TANSTAAFL!