Class and function advice

[diafol]

Hi All.

I'm getting to grips with OOP (slowly) and I was wondering how you go about applying general functions to classes.

For example, if I have a few general functions - this is a silly example, but should give you an idea of what I'm asking:

function strBig($str){
   return strtoupper($str);
}

class fixMe{
  public function doSentence($str){
    return "This is my " . strBig($str);
  }

}

$out = new fixMe;
echo $out->doSentence('dog'); //outputs This is my DOG

OK, rubbish example, but the thing is I need to use some formatting functions (e.g. date) that may be used across a number of classes. Would you suggest using the type of thing above - i.e. separate function and class or use a strBig method from a static class (or singleton) for example.

I'm aware that I should be trying to decouple the classes, so any thoughts on this would be appreciated.

[scarcella]

My advice create a class called something like general, then just extend the class fix with general. So then you can use those functions in the general class. I hope you get what i am saying.

~Marais

[diafol]

Yeah, I get it - thanks for the feedback. It's just that it just seems a bit 'odd'. I'm still a real noob at OOP, so perhaps I've got the wrong end of it. I thought that subtypes should have some sort of relationship to the parent. As I mentioned, I just need to use a few formatting functions/methods across a number of 'parent' classes. It looks as though I'd be subtyping all of them just to run a few formats.

I was thinking more along the line of:

$this->genFuncs = genFuncs::getInstance();

So I can access all the formatting methods via $this->genFuncs->methodName() in my fixMe class

I've read a bit about Singletons saying that they should have no place in php! Some heated stuff about that. Sorry if I sound as if I'm not taking your advice, it's just that I've got so much more to learn and I'm not the sharpest tool in the box! :(

[pritaeas]

Make a base class for your classes. Put your general functions there. Every descendant will have them.

[jkon]

Of course there could be many approaches, but as I understood from the given examples you are talking about utilities classes (with general functions) . If this is the case could be best if you separate them based on what the subject argument is. That way you could have, let’s say a StringUtil class, a CurrencyUtil and so on… Generally speaking most utilities classes have simple (without extensive logic) methods under static scope, so are not objects.

There is a catch to utilities classes, if you overuse them or add complex tasks on them you end up writing “object oriented” but in a procedural thinking way (I don’t believe that will be the case for you ardav , because as an experienced programmer you are , I am sure that you can distinguish the differences in the way of thinking OOP and procedural) .

[diafol]

because as an experienced programmer you are , I am sure that you can distinguish the differences in the way of thinking OOP and procedural) .

You flatter me jkon. But that's my problem. I'm getting trouble thinking OOP having programmed most of my stuff in amateurish procedural.

Thank you Prit, that seems in line with marases told me.
jkon - you've shown me how it could be done in the way I was thinking about it, but it seems that this is not advisable.

So on balance, I take it that static classes or singletons are not the way to go with this and I should be looking to create a base class after all. Will have to radically rethink the way I was going to refactor my old procedural stuff.

Thanks everybody for the input.