Thanks Scott,

That's kind of what I thought -- that there's no cut-and-dried answer to 
the question I asked.  I'm actually amazed that it came out coherently 
enough for someone to understand it and answer!

Your solution is a good one.  On the one hand this is less modular, 
since it tests for certain conditions that have to exist (i.e., the 
POSTed variables) and thus requires a completely different method for 
completely different conditions, but on the other hand, it does nicely 
keep all of the code in the class so that the script doesn't get bogged 
down with many method calls.  I do one call to dothis(), which does all 
my work, and then I'm done.

That's what I'll go with, thank you.


On Thursday, June 6, 2002, at 05:09  PM, Scott Hurring wrote:

> It depends highly on what you're doing and how you're doing it :)
> If somethign needs to be done *always*, just throw it into the
> Object so that the user won't have to call it explicitly,
> however if you want to provide fine-grained control over
> how/when/why things are cleaned-up, you might want to
> keep it "public" and let the user call it explicitly.
> For example, if clean-up is automatic, and only once-per-session,
> this might be somewhat along the lines of what i think you're
> asking for:::
> function dothis($form)
> {
>   // ..... do whatever to POSTED variables
>   $this->cleanup($form);
> }
> function cleanup($form)
> {
>   // Only run once per instance
>   if ($this->cleanup_called)
>       return 1;
>   $this->cleanup_called = 1;
>   // ... do cleanup
> }
> ---
> Scott Hurring
> Systems Programmer
> EAC Corporation
> Voice: 201-462-2149
> Fax: 201-288-1515
>> -----Original Message-----
>> From: Erik Price [mailto:[EMAIL PROTECTED]]
>> Sent: Thursday, June 06, 2002 4:58 PM
>> Subject: [PHP] OOP style question
>> I'm trying to solve my earlier-posted dilemma of a class attribute
>> (array) that is "remembering" elements that should have been
>> unset().
>> The good news is that, according to some testing I've been
>> doing (I have
>> separated the relevant code and am directly testing it), it
>> looks like
>> PHP is behaving as expected -- I really hope that it's just
>> an error on
>> my part, so that I can fix it.
>> But out of this exercise I have begun to wonder something.
>> If someone
>> who is better-schooled than I in object oriented programming
>> style could
>> respond I would be very grateful.
>> I have a method in my class that essentially unsets an array
>> element.
>> The frequency with which this method is called varies
>> depending on the
>> circumstances, so i can't "hard-code" the solution to this
>> problem.  But
>> after the method is done being called (however many times it need be
>> called), a second method needs to be called.  Think of this
>> second one
>> as a "clean up" method, that needs to be called anytime the
>> first method
>> is called, but ONLY ONCE per script instance, no matter how
>> many times
>> the first method was called.  This means that I can't just
>> call method
>> #2 every time I call method #1.
>> Now, originally I was doing all of this method calling from
>> the script
>> itself.  For each variable POSTed by the user, I call the
>> first method.
>> But now that I have a second "clean-up" method that needs to
>> be called,
>> how should I go about it?  Should I have one "master" method in the
>> class that is called from the script, and itself does all the work?
>> This keeps all of the work in the class, and out of the
>> calling script.
>> OR...
>> Should I keep the class free of code that only executes according to
>> POST variables from the user, and keep this kind of thing in
>> the calling
>> script.  That way, the object's class is more flexible, and
>> can be used
>> in more contexts.
>> Again, this is really a question of style -- I can get it to
>> work either
>> way.  I'm just wondering if a class should be written to
>> handle ALL CODE
>> related to its class, and keep most of the work in "private" methods
>> (not really enforced in PHP but whatever), or whether the
>> class should
>> be written so that it has a lot of public methods that can be called
>> from the script, which means that the class is more flexible
>> in the long
>> run?
>> A question of encapsulation vs modularity, it would seem.
>> Your thoughts are gratefully accepted.
>> Erik


Erik Price
Web Developer Temp
Media Lab, H.H. Brown
>> --
>> PHP General Mailing List (
>> To unsubscribe, visit:
> --
> PHP General Mailing List (
> To unsubscribe, visit:

PHP General Mailing List (
To unsubscribe, visit:

Reply via email to