On Sun, 2004-02-22 at 07:25, Sztankó Demeter wrote:
> I'm not sure that I want to start OOP-ing in my php code, but I will if
> necessary.

Ok, I have below a non-OO response.  Personally, while I enjoy the OO
methodology, I don't think it is the "one true way."  I adhere to the
philosophy that anything that can be done using OO can also be done
without it.

> I'l tell the problem I want to solve. It also will help me to understand the
> problem:
> 
> There are two (or more) different functions on my web site, that have the
> same name (an action). They are called depending on the permittions of the
> end user. (for example, if it is an unregistered user, then it is redirected
> to registration form, if it is a registered user, some table is generated
> from database, if it a administrator user, some additional controls a shown
> that allow to change the table). I want to have the code clean so I don't
> want to put the switch or if operators to it. I will call the wrapper that
> will check the grant of the user and call apropriate function. (For example:
> Load_action("List"))
> 
> So there is a set of grant properties assigned to each function and a list
> (array, whatever) of such functions is assigned to the action. The wrapper
> walks through the list and finds the first function which grant properties
> match the user grant properties.
> 
> The second side is that I want to make the coding very easy and simple. So
> if I want don't want to bother with the name of the functions a write for
> the action. I want to write the function, and call some method that accepts
> action name and a permission set as an argument (permission set will be a
> string that will be evaluted by the wrapper), for example  :
> Add_function_to_container("List","(P_READ AND P_WRITE) OR P_ADMIN","Some
> kind of description of this function");
> This method adds the copy of function to array then deletes the original
> function, so I can use the same function name next time. (For simplicity,
> the function names is always the same as the action name, so it always knows
> which function to add)
> 
> This will also simplify the process of writing developers documentation.

I like your approach, I am glad to see someone wanting to use some
design forethought to save time down the road.  Just make sure you stay
flexible.

> 1.
> I wouldn't be so lazy and will make another function name. For example if
> there is an action called List, then there will be following functions:
> function Action_List_1()
> function Action_List_2()
> function Action_List_3()
> The wrapper then looks up for the new function with the help of
> get_defined_functions() and adds the Action_List_...() function that is
> still not in the list.

One spin off on this design would be to setup a naming convention to
your functions.  Action_List() could become:
Action_List_nouser()
Action_List_user()
Action_List_admin()

You could have a function that pairs a "List" call with the user's state
and generates the function call:
$func = 'Action_' . $func_name . '_' . $user_state;
$output = $func($args);

> 2.
> I will make same kind of an abstract class called the same way as action and
> there will be derived classes that implement the functions.
> This sounds nice but a little bit cumbersome. There will be 200 actions and
> I don't want to write an abstract class for each of them.This contradicts my
> philosophy of lazyness.

You can aggregate this with the Command pattern Michal mentioned
earlier.  I would recommend using a variation of the Command pattern to
collect your actions, then use the Factory pattern to manage your user
states and select the appropriate set of actions.  This will give you a
lot of flexibility down the road at the expense of some additional
programming now.  You should not need to create abstract classes for
each action, however you will need classes to handle creation,
execution, etc. of these classes.  IMHO laziness is a boon to
programming, over implementation will be the death of us all. :)

> 3.
>  Some great idea that You will provide. Maybe based on OOP, maybe not, but
> it is easy to code and perfect.

Here's another non-OO solution.  You could define these functions in
their own files.  For example, hold all the admin versions of these
functions in an admin include, do the same for user, etc.  Then include
the appropriate file based in the user's state and proceed from there. 
You will not need to worry about having duplicate function names, though
the implementation will be somewhat unique.  Also, if a user changes
state you will have to issue an HTTP redirect to reload the correct
functions.  Fortunately, I would guess that would rarely, if ever,
happen in the middle of a script's execution.

In looking for a non-OO solution, my opinion is that option 1 would be
the best.  It is easy to implement and documentation/code reading will
be easier as time passes.  Having multiple functions with the same name
performing different tasks presents a rather steep learning curve to
someone who has to maintain your code.

Regards,
Adam

-- 
Adam Bregenzer
[EMAIL PROTECTED]
http://adam.bregenzer.net/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to