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.

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

6 Years Ago

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! :(

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

6 Years Ago

because as an experienced programmer you are , I am sure that you can distinguish the differences in the way of thinking OOP and 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.